How to Get Started with vCloud Connector - Part 2

This is a repost from Chris' personal blog, ChrisColotti.us.

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.

1. The Virtual Machine is Exported from the source location and temporarily stored on the vCloud Connector Node’s local space
2. Once the export has completed from the source an import is initiated to the destination
3. 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
4. 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.

http://blogs.vmware.com/.a/6a00d8341c328153ef0162fdbff547970d-pi

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.
http://blogs.vmware.com/.a/6a00d8341c328153ef0162fdbff8ba970d-pi

http://blogs.vmware.com/.a/6a00d8341c328153ef01675eb3cbfa970b-pi

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.

http://blogs.vmware.com/.a/6a00d8341c328153ef0162fdbffb75970d-piNow 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.

http://blogs.vmware.com/.a/6a00d8341c328153ef0162fdbffc7f970d-pihttp://blogs.vmware.com/.a/6a00d8341c328153ef01675eb3d06b970b-pi

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.

From Private to Public vCloud

Now comes the fun part.  As before I am using my Virtacore vCloud Express account  to move the workload from my on premise vCloud to the Public vCloud.   The process is similar to the vCenter move, but now we are going vCloud  to vCloud via the internet instead of local network.  Remember that  depending on your provider you may have multiple vCloud’s behind their  portal as is the case with Virtacore.   Therefore if you have a true template, you may want it on both  vCloud’s for local deployment.  If your workload is an actual vApp, you  can decide which cloud you want to run it in.  Again you need to ensure  you have a Catalog available in both your provider based vCloud’s for  this to work.

First we select the “Production” workload from the local Private vCloud on premise and copy it to the remote vCloud Catalog.

The same as before only now you see the source is my local vCloud and the target vCloud is the Virtacore Los Angeles in  my Public vDC on my Organization Catalog.  We also see in the vCloud  Connector interface the progress of the copy.  As a reminder, I am using  a test Virtual Machine with only a 25MB virtual disk to make this go  quicker for test purposes.

Once this process is completed, I could run another copy from my on  premise to the remote vCloud to have this same vApp available on the Virtacore Virginia vCloud Express location, or I could copy it from the LA to VA vClouds and let theVirtacore network handle the transport.  Instead I am going to simply deploy it to the LA vCloud.

Here  I get my options for deployment to the vCloud in LA so I can deploy it  from the Catalog.  I can select my vDC, name the vApp, as well as select  the network from the options available.

Once deployed it will show up in the Virtacore portal as a new vApp for me to power on and manage as I see fit.  I did find out the Virtacore portal does have a caching setup so it may take a couple of minutes for it to show up, but it will.

At  this point I can configure my vApp and when I am done I can use vCloud  Connector to remove the version of the template in the Catalog.  Again  you may want to have a copy in your other hosted vCloud for future use,  or you can remove it completely

Summary Review

What all this testing has shown me is that the combination of a hosted provider like Virtacore along  with the vCloud Connector architecture provides a pretty powerful way  to move workloads between clouds.  There are a few things you need to  understand and get used to in the way of the architecture, user  interfaces and other aspects.  Once you nail those down you can start  copying workloads between your clouds and at the very least get copies  of your templates and vApps into a public cloud provider to experiment.   What this has also done is allow me to take feedback of my findings  back to the vCloud Connector team as feedback to possible adjustments in  the future.

The key to remember is this is slightly different from the 1.0  product in the sense that you have to copy, deploy, and remove the vApp  and that Catalog’s are required to facilitate the moves.  As with Part One, I wanted to thank Virtacore for  being kind enough to provide me the public cloud space for this  testing, and let you know they are offering $50 off the initial use of  their vCloud Express product so folks can give it a shot.  Just use the  code STEKREF when you sign up to get the offer if you sign up and check out their new portal as well.

Chris is a Consulting Architect with the VMware vCloud Delivery  Services team with over 10 years of experience working with IT hardware  and software solutions. He holds a Bachelor of Science Degree in  Information Systems from the Daniel Webster College. Prior to VMware he  served a Fortune 1000 company in southern NH as a Systems  Architect/Administrator, architecting VMware solutions to support new  application deployments. At VMware, in the roles of a Consultant and now  Consulting Architect, Chris has guided partners as well as customers in  establishing a VMware practice and consulted on multiple customer  projects ranging from datacenter migrations to long-term residency  architecture support. Currently, Chris is working on the newest VMware  vCloud solutions and architectures for enterprise-wide private cloud  deployments.