Data Center Extension to VMware vCloud Hybrid Service aka vCHS

With the release of vCC 2.0, most of you have noticed that we have introduced a new feature called Data Center Extension aka DCE within vCC 2.0. Now we want to show case how you can leverage that functionality with our IaaS offering which is vCHS aka vCloud Hybrid Service. Before I jump onto the example part and taking a step by step approach, I wanted to touch base on the architecture and use case side of DCE.

DCE Overview

It extends the enterprise network to public cloud, move VM from private to public cloud while retaining the same IP/MAC address.

It is a Layer 2 extension from existing enterprise network to public cloud over secure SSL  VPN Tunnel. Using this you can move a VM from enterprise network (vSphere or vCloud Director) to public cloud but still retail the same IP/MAC Address. Once you are done you can consume and manage the moved VM with the same IP/MAC address. However this feature requires vCC Advanced edition license.



DCE – What happens in the background

It is divided into 3 major phases:

  1. Infrastructure – Creation of target vApp network, modification of SNAT/DNAT rules and creation of the “SSL VPN” tunnel.
  2. Copy – Standard OVF export and copy process.
  3. Deploy – Deployment of the OVF template to the target cloud.


DCE Use Case

It is a ideal use case for occasional high volume VM. For an example it is ideal for Retail industry with high volume shopping season.

  1. Large department store chain needs extra transaction processing for some month period.
  2. Purchases space on a Public Cloud (vCHS) instead of buying additional hardware that’s redundant for the rest of the time.
  3. Configures transaction processing VMs on their own Private Cloud and then moves them to the Public Cloud without having to reconfigure.



Key differences between DCE and Standard vCC VM Copy are:

  • VM retain it’s IP and MAC Address
  • Any Firewall / NAT rules etc are retained
  • The operation is called a Stretch Deploy as opposed to Copy/Deploy
  • The target for a Stretched Deploy will always be a vCloud Organization


DCE Preparation

Performing a stretch deploy is a straight forward method however there are very stringent rules and limitations that must be followed when preparing the source and target environment:

  • Software version has to met the compatibility factors
  • vCC Advanced licensing has to be there
  • Network configuration has to be proper. Be ready with External networks and public IP Addresses.
  • VM and vApp preparation


DCE Network requirements

As discussed earlier, the retention of VM’s MAC and IP Address is made possible by establishing an SSL VPN Tunnel between source and destination vApp. That means this requires that the vApp where the VM lives to have a vShield Edge for its network and have an external IP that is reachable from the target cloud.

Source vSphere On Prem Cloud

  • You need to deploy vShield Edge manually and must have a single external network
  • Be reachable from the Internet or target network
  • Have an internal interface connected to a vDS and this has to be 5.1.0
  • IP allocation can be either static or dynamic (DHCP)
  • vSE can be compact or large


Step by Step approach

Source vSphere and vApp Preparation

Let us now look at how we can configure our source environment first for the DCE operation. I have segregated in steps.

  1. Deploy vShield Manager (5.1.2) as the way you normally do it
  2. Register it with the vCenter Server (On Prem Private vCenter)
  3. Assuming vDS is already configured, create a dVPG for the external interface of vSE.
  4. Create another dVPG for the internal interface of the vSE
  5. Open up vSM Web Interface -> Click on the Datacenter on the left hand side and click on Network Virtualization on the right side.
  6. Click on the Edges link.
  7. Click on the “+” icon to deploy an Edge.
  8. Specify a name of this Edge and click on Next
  9. Select default on the CLI credentials page and click on Next
  10. In the Edge appliance select either Compact or Large.
  11. On the Edge Appliances section, click on “+” sign.
  12. Select Cluster where this Edge is going to be placed and datastore too. Click on Add.
  13. Click on Next.
  14. In the Interfaces section, click on the “+” sign to add the internal interface first.
  15. Specify a name “Internal”. Select the type as Internal. Click on Select to connect this internal interface to a dVPG.
  16. On the configure Subnets section, click on “+” icon.
  17. Specify the subnet mask (in this example /24). Click on “+” sign there and specify the internal interface IP address (in this case Click on OK. Click on Save. Click on Add. So at this time, your internal interface is ready. Now you need to add the External interface. Follow the same procedure to add the external interface.
  18. Click on Next.
  19. Specify the Default Gateway (typically external interface) and click on Next.
  20. Click on Configure Firewall default policy and select default policy as Accept.
  21. Click on Next and click on Finish. Your edge will be provisioned and you can see it has two legs.


Now as a simplification of the process, I have configured DHCP on this Edge device so that it can give DHCP IP Addresses for my VM connected to the internal interface of the Edge.

  1. On the Edge screen, double click on it to open up the Edge services screen.
  2. Click on DHCP Tab.
  3. In the DHCP Pools section, click on the “+” icon, specify start IP and end IP and click on Add.
  4. Click on Enable button to enable this service.


  1. Now create a vApp and put at least two VMs there.
  2. Attach the VM Network adapter to the internal portgroup where in DHCP broadcasting is happening through vSE.
  3. Power on the vApp and make sure you are getting the IP Address from this DHCP scope.
  4. Also ping the Gateway ( and each VM to make sure that internal network is reachable.



With this you end up configuring the vSphere and vSM side of it. Now you need to start configuring the vCC Node and Server.

vCC Node and Server Preparation


In order to accomplish this you will need to do the following

  1. Install VCC Server and VCC Node in Corporate Environment
  2. Install VCC Node in your vCHS instance



Go to GA&productId=289 and download VCC 2.0 server and node virtual appliance. These virtual appliances can be installed either on Virtual Center or vCloud Director.


Please Refer VCC 2.0 documentation center 20/index.jsp for detailed documentation on installation and user guide


Internal Corporate Server

Install VCC Server and one instance of VCC Node. Refer VCC 2.0 documentation center 20/index.jsp for detailed documentation on installation and user guide


vCHS Instance

Install one instance of VCC node on vCHS/destination cloud. Refer VCC 2.0 documentation center 20/index.jsp for detailed documentation on installation and user guide


Register Clouds to Correspond VCC Nodes

Internal Corporate Network

  1. Login to https://<VCC-NODE-IP>:5480 using admin/vmware  as username/password
  2. Select “Node” tab
  3. Select Cloud type as vSphere for VC and enter the vCenter URL
  4. Check Ignore SSL cert and Use Proxy check boxes as

vCC OnPrem Node


VMware vCHS Environment

  1. Login to https://<VCC-NODE-IP>:5480 using admin/vmware  as username/password
  2. Select “Node” tab
  3. Select Cloud type as vCloud Director for
    vCD and enter the url of the vCD instance you are assigned
  4. Check Ignore SSL cert and Use Proxy check boxes as


Register VCC server to vSphere client VCC user interface 

  1. Login to https://<VCC-SERVER-IP>:5480asadmin/vmware
  2. Goto“Server”tab
  3. Click on “vSphere client” tab, provide the VC details and click on register to use vSphere client for VCC user interface

vCC Server vSphere Client



Register VCC nodes to VCC server

  1. Login to https://<VCC-SERVER-IP>:5480asadmin/vmware
  2. Goto“Nodes”tab
  3. Click on “Register Node” and provide the node details as below
    and register both the corporate VCC node and vCHS VCC node to VCC server.

vCC Server Node Reg

Registered nodes will be listed under “Manage Nodes” on the “Nodes” tab. Ensure that the nodes are in “Up” state.

vCC Nodes in Server


  1. After registrations are complete, open VCC UI through vSphere client
  2. Click on plus sign in the clouds inventory panel to add the registered clouds as shown in the below screen shot.OnPrem
  3. Add Cloud wizard will list the available clouds registered to VCC server, select one cloud and enter the user name and password for the cloud.
  4. Click on the source cloud, Inventory panel will list all available VMs, vApps and Template in the cloud.
  5. Repeat the same step for the vCHS instance as well.



Advanced Option

To use VCC advanced features like Content Sync and DCE enter the license keys on VCC server VAMI UI. Please see 20/index.jsp


Perform a Stretch Deploy of a VM

  1. To allow the Stretch deploy to happen the Datacenter Extension settings need to be updated on the vCloud Connector Server
  2. Open the Browser go to the vCC Server and Login
  3. Go to the Nodes tab, find the On Prem Node and click on the “gears” icon on the far right under the Actions column
  4. Select Datacenter Extension Settings and enter the On Prem vSM details and click RegisterOnPremDCE
  5. Repeat steps 3 & 4 except this time you will be using the vCHS Node and entering credentials for the VCD Public Org
  6. Reload both the clouds on vCC UI


Note: Incase if the source requires proxy to reach the vCHS environment, both vCC server and vCC node on source side should be configured with Proxy server.


Now the source and destination clouds are enabled for DCE.


In order to run DCE source VM should be part of a vAPP which is connected to routed network. Incase of VC the vApp should be connected to edge. Incase of vCD, vApp network should be created and this vApp can be connected to Org direct or routed network.


Once completed go back to the vCloud Connector interface in vSphere and click on On Prem Node then the Virtual Machines tab, highlight the Memhog2 VM then Stretch Deploy. A wizard will appear, please complete as follows:

  • Source Catalog
  • Cloud
  • Stretched vApp Name
  • Target Catalog
  • Target VDC
  • Network
  • External IP / Public IP
  • Power on deployed entity






Click Next and then Finish. Click on Tasks on the left and you will see the Deploy Stretch Virtual Machine tasks progress in the center panel.




Specifically, vCloud Connector does the following.

  1. Verifies that the network of the VM or vApp on the private datacenter can be extended.
  2. Creates a new routed vApp network in your Organization VDC in the public vCloud.
  3. Creates NAT and firewall rules in the public network, if required.
  4. Creates NAT and firewall rules in the private network, if required.
  5. Creates an SSL VPN tunnel from the vShield Edge of the private network to the vShield Edge of the new routed vApp network in the public vCloud.
  6. Copies and deploys the VM or vApp into the new routed vApp in the public vCloud.



Now login to the vCHS Portal and Go to your vDC and check the VM. It should retain the same IP Address as it had in the source.



Now look at the VPN tunnel and in this example I can show you from my On Prem vSE Tunnel. It should be up.

VPN Tunnel


At last I will try to ping the on prem VM from this DCE’d VM in vCHS to understand the connectivity.



Caution !! After a Stretch Deploy

  • Once you are done with the stretch deploy you need to keep these points in mind:
  • Do not power on the source VM. It will cause an IP/MAC conflict
  • Do not delete the source VM. The reservation of IP/MAC may get lost
  • Do no change anything on the target vShield Edge or routed vApp network. It will impact the routing of traffic to the target VMs.


Finally, after one VM has been stretch deployed from a vApp, all other VMs that are stretch deployed will skip the “Infrastructure” step as the target vApp and SSL VPN Tunnel has already been established.


Food for thought

1. Do you know how can you get your VM back in your On Prem Cloud after a DCE? This is typically called Reverse DCE.

2. Do you know how can you protect your DCE’d VM and restore the service once you (accidentally?) delete your VM (vApp)? If your answer is no then read here.


Tune in here to know the answer of these two questions. If you know already, then point me to it 🙂



About Prasenjit Sarkar

Prasenjit Sarkar is a Product Manager at Oracle for their Public Cloud with primary focus on Cloud Strategy, Cloud Native Applications and API Platform. His primary focus is driving Oracle’s Cloud Computing business with commercial and public sector customers; helping to shape and deliver on a strategy to build broad use of Oracle’s Infrastructure as a Service (IaaS) offerings such as Compute, Storage, Network & Database as a Service. He is also responsible for developing public/private cloud integration strategies, customer’s Cloud Computing architecture vision, future state architectures, and implementable architecture roadmaps in the context of the public, private, and hybrid cloud computing solutions Oracle can offer.

6 Replies to “Data Center Extension to VMware vCloud Hybrid Service aka vCHS”

  1. Pingback: Disaster Recovery of Stretched VM (DCE) in vCloud Hybrid Service aka vCHS - Stretch Cloud - Technology Undressed

  2. I posted some detail about this process a week or so ago but this statement does not make sense nor is it realistic to most vSphere only customers:

    “In order to run DCE source VM should be part of a vAPP which is connected to routed network. Incase of VC the vApp should be connected to edge. Incase of vCD, vApp network should be created and this vApp can be connected to Org direct or routed network”

    In a real vSphere setup most customers would not have a vSphere vApp nor would they be routing already through a vShield edge or expected to change the Default Gateways of all their existing Virtual Machines. I actually cover this in my posts specifically as a real word setup and use case.

  3. Pingback: 【VMware混合云】应用为王 | cloud(

  4. Pingback: VMware vCloud Hybrid Service Beta Impressions | TheSaffaGeek

  5. Pingback: VC to vCHS DCE for Dummies! | Complaints Incorporated...

  6. Pingback: Technology Short Take #35 | Strategic HR

Leave a Reply