It’s taken me a bit of time to get to this third post, but with VMworld looming less than a week away, needless to say it’s been a little busy. The purpose of this post is to simply explain some advanced options in using vCloud Connector and Stretch Deploy to suit your use case. It’s important to know a few key things about the current behavior of vCloud Connector’s copy processes before I continue.
vSphere to vCloud Air, (V2C), Migration
Really this topic has come up quite a bit and you will hear me talk a lot about it at VMworld. The basic idea is not unlike that of the original P2V (Physical to Virtual), process. The difference here is we are using vCloud Connector to do the migration and we need some manual intervention to complete it. It is important to know the items above before you begin, but I will attempt to document what I have done successfully in my testing to migrate vSphere virtual machines to vCloud Air intact with nothing but an IP and MAC address change. This V2C, (vSphere to Cloud), process exactly like a P2v would be with an added IP change.
Things to Know About the vCloud Connector Copy Process
- When you do a copy your Virtual Machine is copied to the vCloud Air catalog
- When you do a copy, by default Guest Customization is enabled on the catalog item
- This means when you deploy your machine from the catalog it will be customized
- You cannot do a direct copy to “My Cloud” to migrate a machine without using fenced mode
- Generally copying an existing configured machine will require an IP address change and will get a new MAC address
Basic V2C Migration Process
This process assumes you have already configured your site to site VPN, created multiple vCloud Organization networks and deployed an Active Directly Controller into your vCloud Air environment. In turn the net networks need to be part of your domain’s Sites and Services so the migrated machine will logon locally to the domain through that domain controller in the cloud. I will be discussing some of this at length in my session at VMworld
- Ensure vCloud Connector is installed and configured for vSphere connection and your vCloud Air account
- Shut down the virtual machine in vSphere
- Initiate a vCloud Connector Copy to a catalog
- Deploy the Catalog item to your cloud but DO NOT POWER ON!! (This is crucial)
- You can even select an existing vApp to deploy it to if you chose
- Edit the virtual machine properties and DISABLE Guest Customization as show below
- Ensure the Machine name in vCloud matches the original machine name
- This will be disabled to prevent power on Sysprep or Guest customization
- Since IP configuration uses Guest customization you will need to manually handle the Guest IP information from the vCloud IP range of the Org Network
- Connect the machine to the correct organization network you want
- Power on the virtual machine
- manually configure networking in the guest to the new org network settings
The result of this procedure is that you get a complete, unmodified virtual machine with the exception of a new MAC address and a new vCloud Organization based IP address. If you have the site to site VPN setup properly with the correct rules that machine should also be able to ping, route, and connect back to on premise resources, while maintaining Domain logon to the local cloud based Domain Controller.
Data Center Extension Advanced Concepts
What we have seen is that there is a use case for Stretch Deploy. I believe most people can live with the easy copy process above with an IP change. In most cases provided the system is part of DNS and that is updated in the procedure as needed and the site to site VPN routes and rules are in place everything will communicate. There is of course the use case where you don’t want to change the IP or MAC address of the machine you are moving. There are a number of reasons for this, the most common might be a licensing requirement of the application. Regardless once you’ve stretched the vSphere VLAN you can do some cool additional things with it. I will say that much of this has been my testing and may not be officially supported yet.
Things to Know About Data Center Extension (DCE/Stretch Deploy)
- In order to stretch a vSphere VLAN you need to initiate it by stretch deploying a Virtual Machine
- Manually assigned IP address are generally used
- The owner of that IP range is usually the network team so IP’s won’t exist in the vCloud IP Pools
- Guest Customization is never done to the machines during the copy process
- Stretch deployed virtual machines are generally not deleted from the source site
- There are a number of reasons for this, but I think many of them are from a vCloud to vCloud scenario where the IP can be re-issued, in a vSphere setup IP’s are not controlled by an IP pool. I need to look into the other reasons.
- Stretched networks in general have some networking considerations
- To be covered in a future post
Generic Stretch Deploy To Create the Network
We know that the stretch deploy in 5.1 is tied to using a particular virtual machine to create the network. You have a couple of options here as myself and a few others see it. You can stretch a real configured virtual machine, or you could in theory stretch a “worker” virtual machine, that is used to simply create the network and VPN. Once that is done you can use the copy process above to migrate other virtual machines where a MAC address is tolerable, but change in IP address is not. For machines that need to maintain both, you would have to do an official stretch deploy as that process will maintain the MAC address as well.
Deploy New Virtual Machines From Catalog
Once you have this network available you can deploy new templates to the newly created vApp and configure them with the settings of the stretched network. You would have to contend with all considerations about how the machine will logon to the domain and how network traffic will flow. I plan on putting together a short ‘Considerations for vCloud Air Stretched Networks’ post as well maybe during VMworld.