In Part One of this two-part series, we examined the deployment of vCloud Connector 1.5, the architecture, and the options for accessing the user interface through the vCloud Connector Portal or the vSphere Client. Here is a quick review of some key points to remember if you read part one previously. Part two will focus on the actual moving of your workloads so you can see just how easy it is once you have it setup.
- Deploy the vCloud Connector Server on Premise initially
- Deploy vCloud Connector Nodes to all connection points you need access to
- Provider clouds like Virtacore will have a single portal, but multiple actual clouds
- The vCloud Connector Server today does not work behind NAT, so deploy on a local subnet
- On Premise components can live outside the cloud, hosted nodes will be inside the provider cloud
- Configure server and node passwords and create real Certificates for SSL between server and node
- Using the portal still requires you have local access to the vCloud Connector Server via LAN or VPN if it is hosted on premise
Once you have the components all setup the fun can begin in moving the workloads. Something to remember and consider is these are full network copies of the Virtual Machines. They must be shut down in order to migrate them between vSphere, or your various vCloud setups. Also if you have not read my series on the Clone Wars, it may be useful since some of the data around copying to and from transfer spaces is interesting. If you have not let’s take a quick look at the process that vCloud Connector does to facilitate the moves.
- The Virtual Machine is Exported from the source location and temporarily stored on the vCloud Connector Node’s local space
- Once the export has completed from the source an import is initiated to the destination
- If the destination is a vCloud infrastructure, the data will be moved through the vCloud Cell’s “Transfer Space” located at /opt/vmware/vcloud-director/data/transfer
- The imported Virtual Machine will then be placed into the vCloud Director instance as a new vApp and the transfer space will be cleaned up.
The reason the Clone Wars series is important is to understand that on a local private cloud the transfer between vCloud, the transfer space and the final storage on ESX is all network copy based. On a provider cloud like Virtacore or others, you will also have that copy going over the internet. So basically, these things can take time to move.
Moving Your Workloads
I want to point out a couple of key changes from vCloud Connector 1.0 and 1.5 as it works today.
- You MUST have Organization Catalogs available in order to copy between clouds.
- The underlying vCloud Director import/export functions use the catalog as a transport mechanism.
- If you do not have any Organization Catalogs you will not be able to copy. In the situation with public cloud providers you may need to have one created if there is not one present. I actually found this with Virtacore, but my account was created a while back. New accounts should be coming with at least one catalog on your Organization to facilitate this. If there is not one just contact the support chains for your provider.
The process is multi-step where vCloud Connector 1.0 did some of the steps for you. What I mean is you have to do the following to get a vApp workload completely moved from one cloud to another.
- Copy the vApp to the remote vCloud Catalog
- Deploy the vApp from the Catalog using vCloud Connector or the vCloud Portal
- Configure and test the vApp now in the new Cloud
- Remove the Catalog item if you do not need it going forward
This may seem like more steps than with vCloud Connector 1.0, but this actually allows you to re-deploy the vApp should you have to for any reason before you remove it from the Catalog. Only once you are sure you’re vApp is in the new cloud and functioning will you want to clean up and remove it. This way you don’t have to do the entire process again.
From vCenter to vCloud
At this point in the game we will assume you are ready to move some workloads around. For my test purposes I created an empty test VIrtual Machine on vSphere with a VERY small virtual disk, and no operating system installed. I did this purely to see the movement, and not have to wait for 20 or 30 gigabyte to copy. Below is the screenshot of all my clouds I setup in Part One, so the first thing to do is move a template from vSphere to my local vCloud Director.
First we expand the vCenter object and locate the test template I created directly in vSphere by selecting the vCenter, then making sure I am on the template tab since this test object is an actual vCenter Template. It is worth noting as well that this vCenter is actually the vCenter appliance, so that also works with vCloud Connector.
If you want, you can also deploy this from vCloud Connector, but we will copy it to my local on Premise cloud first then move it to the public cloud. When we select “Copy” We are given the options box.
Now we can also select the VDC import
Now we can also sect the Catalog for the import and select “Copy”
What we see is that the copy exports from vCenter and completes the import to the vCloud Catalog.
With a refresh of the vCloud connector view we can see the template in the catalog of vCloud Connector’s interface and we are ready to deploy it for use by selecting the deploy option. However, I will jump over to moving a workload from a Private vCloud to a public vCloud as that may be more interesting.