*In light of the clarification, by VMware, that VXLAN is not required for vCloud Connector Datacenter Extension (DCE), I took content from my original post to create this post, explaining how DCE actually works.

VMware recently announced the general availability of vCloud Connector 2.0, their hybrid cloud management solution and a component of the new vCloud Suite offering.  Among the new features announced in the Advanced version of vCloud Connector 2.0 is Datacenter Extension (DCE), aka. Stretch Deploy; this feature allows workloads to be migrated across different clouds, including private to public clouds, without having to change network settings, such as the MAC and IP addresses of the migrated VMs.

vCloud Connector

vCloud Connector is a VMware product that allows users to operate and to manage hybrid clouds that are built using VMware’s vCloud technology.  One feature being promoted is for a public cloud, operated by a vCloud service provider and built using vSphere and vCloud Director, to offer the ability to have vApp workloads copied to it from a customer’s private cloud.  The use cases may be a customer who needs to burst up capacity at quarter-end or to enable workload mobility in preparation for a potential disaster.  At a high level, the process works as follows:

1. The virtual machines or vApps to be copied are powered down
2. The vCloud Connector at the source cloud copies the source VMs or vApps as vApp templates
3. The copied VMs or vApps are deployed at the target cloud
4. The copied VMs or vApps are powered on after deployment

Prior to version 2.0 and the introduction of DCE/Stretch Deploy, this workload migration required that VMs, when copied and deployed to the target cloud, have their network configurations changed to allow them to be accessed in their new location.  The promise of DCE/Stretch Deploy is to simplify and to accelerate workload mobility by removing the network reconfiguration requirement.

Datacenter Extension/Stretch Deploy

Datacenter Extension in vCloud Connector is accomplished by creating a layer 2 SSL VPN tunnel between a user’s private cloud’s vShield Edge instance and a public cloud provider’s vShield Edge instance.  VMs or vApps are copied using this encrypted tunnel which extends the user’s private network boundary to the provider’s public cloud, so that the copied VMs will retain their MAC and IP addresses, as well as the same NAT and firewall rules.  The process is outlined in the vCloud Connector User Guide and reproduced below:

1. vCloud Connector 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.

The keys to making this work is having a good understanding vSphere networking and security and collaborating with your vCloud service provider to ensure networks are configured properly at both sites, as per the User Guide.  It is noteworthy that DCE/Stretch Deploy does support VXLAN, but does not require it or rely on it as the underlying mechanism for extending the source network.  I am also interested in seeing how technology from VMware’s Nicira acquisition may be incorporated  in the future.