My Cloud Consumer Experience – Episode 3: Moving vSphere Workloads into the Cloud

Everybody says the future is in hybrid clouds. In fact that's where I think the "trust" in private clouds and the "flexibility" of public clouds will find the compromise: it will be a mix of both. The ultimate goal is for a cloud consumer to be able to deploy a workload onto either a public or private cloud using the same tools with a completely transparent experience. In the first episode of this series of posts we explored the cloud on-boarding experience with VMware partner Stratogen. In the second episode we explored how to start consuming the cloud we have subscribed to. Building on that, this third episode will illustrate how to move existing vSphere workloads into the cloud as the first (yes I agree.. rudimental) step towards the hybrid cloud vision. In fact if infrastructures are incompatible, moving workloads between each others may prove to be difficult (although not impossible admittedly). Stay tuned on the topic as there are a few other episodes in the pipeline that I am looking forward to publish.

Recently Amazon announced a feature to move vSphere workloads onto EC2. This episode isn't much different meaning that I'd like to show you how simple it is to move a vSphere workload into any vCloud Director based cloud. A VMware sales person would argue that moving a vSphere workload into a vSphere based cloud is much easier than moving it into a non-vSphere cloud but hey, I am a geek, and I still have a lot of respect for what Amazon has been able to achieve so far.

The scenario that you need to think about for this third episode is as follows: I am a vSphere administrator and I have subscribed with Stratogen for some additional compute capacity (episode 1). I have started to deploy some workloads in the cloud (episode 2) but I now want to move some existing workloads from my local vSphere infrastructure into the cloud. Let's get started.

Moving a vSphere template into the cloud

The first thing I want to do is moving some of my standard template into the cloud. In real life, end-users may have both templates and actual workloads stored and running in the local vSphere deployments. When deploying brand new workloads in the cloud they may want to do so from an existing template which represents their standard "company stack". This may be a Red Hat 5.5 image for example. So I am going to locate my Red Hat template image on vSphere and export it in OVF format:

The amount of time it takes to export is usually proportional to the size of the VMDK file.

Once I have exported the template I can now import it into my vCloud Director based cloud. If you remember from the second episode I have already created a TurnKeyLinux image in my private catalog. Now I am going to import my vSphere template. In order to do this I click on the "Upload" button in the screen:

This opens up the upload java app:

As you can see I have an option to choose the target virtual Data Center and catalog. In my case I don't have too many options since Stratogen assigned to me only one vDC and I have created, for the sake of simplicity, one single private catalog in my organization.

Last but not list I now need to locate my OVF descriptor in the folder where I have exported the template ("c:/StagingArea/Red Hat 5.5" in my case):

And the upload begins. The time it takes to upload the template usually depends upon its size as well as the bandwidth available between where the files exported are located and the target cloud.

And here it is the original vSphere template ready to use in the cloud:

If you are interested in diving into more details regarding the catalog capabilities in vCloud Director you can have a look at this article.

Moving a vSphere workload into the cloud

We have just demonstrated how to import a template into the private org catalog for future brand new workloads deployments. Moving an actual vSphere workload into the cloud is a similar process but there are a few details you need to be aware of. For the sake of  keeping it simple and quick we will demonstrate how to move an existing single virtual machine. A similar procedure can be used to import an existing vSphere vApp into the cloud.

I have located a VM in my vSphere environment that I'd like to move to the cloud. This is a training application that I rarely use and I have determined that it is a good candidate for a public cloud hosting model. This VM is a standard standalone Windows 2003 machine that doesn't require any specific interaction with other local infrastructure services. It has been configured with a DHCP address and the local DHCP server has provided this VM with IP number 172.16.100.132.

First and foremost I need to power off your virtual machine. I would then export this VM like we have exported the template in the steps above. The first thing to note is that vCloud Director doesn't support uploading a VM directly into the Org vDC "My Cloud" so I have to first upload the OVF into my organization catalog just as if it was a template. We are basically using the catalog in this case as a buffer.

I will follow the same steps I have used to upload the Red Hat template and I'll see my TrainingApp VM there:

I can now right click on the template and "Add (it) to My Cloud":

And the deployment wizard gets started. For consistency I am calling the vApp TrainingApp:

And then I leave the default VM and Windows names set to TrainingApp (again for consistency).

Note above that I am connecting this VM to the Direct Internet Connection available in my organization. See my first episode to get a proper background of my actual organization network configuration. In a real life environment you may not want to connect directly a Windows VM to the Internet like this. I have done this for the only purpose of demonstrating how to connect a VM to a network. Most likely you may want to connect the vApp to a NAT/Routed network with the proper IP mapping and firewall configurations in place.

After a few minutes the vApp is ready in "My Cloud":

And this is how the TrainingApp VM inside the vApp construct looks like from a networking perspective. Note that vCD assigned an IP from the Static IP Pool associated to that Direct Internet Connection that is under control of Stratogen.

The last thing to keep in mind is that what I have shown here is the very core capability of moving virtual machines from vSphere to vCloud Director (and possibly viceversa if needed). I wanted to stress about the idea that moving workloads across compatible platforms running the same backbone engine makes the overall hybrid cloud story way more simple (from a virtual machine format perspective). What I am NOT showing here is the coordination and orchestration of the whole process. If you have noted, at the end of the steps to move a workload into the cloud you end up with the TrainingApp VM in vSphere, the TrainingApp template in the cloud catalog and the actually instantiated TrainingApp vApp in the cloud. This will require a certain amount of coordination in an actual production environment. Specifically you may want to decommission the vSphere VM and the (transient) template when you are done moving the actual workload into the cloud. Demonstrating something like this is beyond the goal of this brief post that, again, was only meant to demonstrate the core infrastructure capabilities and the easiness of moving workloads without having to touch the Guest OS in terms of drivers and things like that.

In future episodes I am going to show how future (not yet announced) hybrid cloud technologies are going to simplify the experience I have shown here.

Massimo.