My Cloud Consumer Experience – Episode 4: Managing Workloads with vCloud Connector

I am very excited about this episode. Today we are announcing a new technology called VMware vCloud Connector and this is going to be the core of this episode. But before you read on I urge you to read this other post of mine that went live together with this and that explains, in more details, what we are trying to do with vCloud Connector and the strategy behind it. This post you are reading is going to be more "show and tell" (that's the idea about these series of episodes). If you want the proper context regarding what vCloud Connector really is then I strongly recommend that you read the blog post I linked above.

Being at the fourth episode I think it's time to do a recap of the previous posts of this "My Cloud Consumer Experience" series. As a reminder these posts are meant to show you the life of a cloud consumer rather than a cloud administrator. Essentially a user (or an organization) that connects as a tenant of a cloud. To achieve this I am consuming some resources that VMware partner Stratogen kindly made available to me. The previous episodes are, in order:

• Episode 1: The On-Boarding
• Episode 2: Basic Cloud Consumption
• Episode 3: Moving vSphere Workloads into the Cloud

I encourage you to read all of them but, at the very minimum, you should read the third episode. The reason for this is because in the third episode I talked and demonstrated how to move workloads from vSphere into the cloud. In this post I am going to show you how to achieve the same results (and better) with a much tighter integration into your usual day-by-day VMware experience. That's what vCloud Connector is in essence. Bear with me.

I assume that, to all of the readers, this is a familiar picture isn't it?

It's essentially the vSphere client view of my VMs and templates. Nothing big. Business as usual. But hang on. Weeks ago I decided to subscribe (first episode) with Stratogen for on-line cloud capacity because I had a need to expand my datacenter and I thought that I'd rather buy on-line compute capacity rather than new hardware. I have started experimenting with importing/exporting workloads to/from the cloud (third episode), however I found that experience to be a bit of a disconnect compared to what I usually do on a daily basis as a virtual infrastructure administrator that uses the vCenter client day in and day out . That's where vCloud Connector comes in. And that should be clear by now if you have read the introduction post I linked at the beginning.

From a technical point of view, vCloud Connector is a small appliance that I need to host on-premise on my local vSphere infrastructure. I will start to import the appliance as a first step. I am not showing you the whole process of how to import it into vCenter. I assume you know how to kick it off. If not: in the vSphere client interface click File, then Deploy OVF template and you go from there. This is an intermediate screenshot I took that shows what I am importing:

Once imported I see the vCloud Connector VM available:

When I power it on the virtual machine starts the boot process for the first time and stops at a given point for me to set the password for future maintenance.

Once the password is set the first boot process continues and this is where the small local database gets created and populated. At the end of the process (a couple of minutes for me) I get presented with this screen:

Note the IP address of the appliance. This is a DHCP address that the virtual machine has received from the DHCP server available in my local datacenter. In a real life environment you may want to change it using the menus available in the interface. For the sake of keeping the setup story short I'll just go ahead with this DHCP address.

Now I connect to the URL suggested (https://172.16.100.154:8443/vccp in my case) and this is what I see:

I will put the FQDN of my vCenter server and the administrative user id and password (note that I have a number of vCenter federated in my lab, that's why you may see me connected to different vCenter servers at any point in time throughout this post):

And the plug-in gets registered into that vCenter instance.

This web interface is not a big deal. It only allows me to register and un-register a vCenter server with vCloud Connector. Essentially you are telling which vCenter server will show the vCloud Connector plug-in. No big deal, the interesting part is still to come.

When I restart the vSphere GUI I see the plug-in available:

If I enable the plug-in it will show up in the vSphere GUI:

When I click on the plug-in I see an empty whiteboard (please note that this blog was based on beta build. Final product may have different UI):

And this is where the hybrid cloud story starts to roll out. This is the pane where you will start to put your vSphere infrastructure(s), your private vCloud based clouds as well as the public vCloud based clouds you subscribed to with your service provider of choice. In this episode I will show how to connect to my local vSphere based datacenter and I also want to connect to my Virtual Data Center hosted at Stratogen. I could obviously add other public clouds I subscribed to, a private cloud I may have deployed in my own datacenter or other vSphere based infrastructures. They would all appear in this single pane of glass enabling a number of homogeneous operations regardless of where the resources are located.

Don't be confused with the plug-in registration step we had to do a few steps above. That was only meant to tell vCloud Director which vCenter server should be able to show the plug-in in the GUI. In most real life scenarios this will be the same vCenter that I am going to catalog in the next step though.

So let's start adding my local vSphere virtual infrastructure into this view. I click on Add Cloud and this is what I get presented with:

The drop down menu allows me to choose a couple of options: adding a vSphere instance (which admittedly is not really a "cloud") or adding a vCloud instance. For this first step I'll use the former and I'll fill all relevant information as you can see above. Once I am done, this is the view I am presented with:

Deja vu? Yes that's right. Look at the very first picture of this post. What I am doing is fundamentally creating, within vCloud Connector, a mesh view that consists of existing vSphere instances and vCloud instances. So far I have added the vSphere view and as you can see it contains the very same information that the first picture of this post is showing (in the standard vSphere UI).

Note that vCloud Connector has separated views for actually deployed vApps (called Workloads) and another view for templates (called Catalogs). The above view is the Workloads view. Here below is the Catalogs view:

Note, again, these templates are the same templates that have been highlighted in the first picture of this post. It's just a different view for accessing the very same objects.

The next step is to add the resources I have available in the Stratogen cloud. So I click again on the Add Cloud button and this time I use the VMware vCloud Director instance type. In doing so, I am basically connecting to the Stratogen cloud using the standard vCloud APIs Stratogen exposes:

When I am done, this is what the pane is showing:

You can see I am connected to the Stratogen cloud, specifically to the IT20 organization in that cloud, and that I have a single Virtual Data Center (aka vDC) called IT 20 Data Center that I can use . If you have the time and patient to read my first post in this series of episodes (Episode 1: The On-Boarding) you'll note that this is exactly what I have subscribed with Stratogen. Note also, on the right hand side of the pane, the workloads that are currently deployed in the organization (and specifically in the vDC). The reason for which I see those workloads deployed is because I have already started "playing" with the Stratogen cloud deploying workloads and creating a catalog in my Episode 2: Basic Cloud Consumption and my Episode 3: Moving vSphere Workloads into the Cloud.

As I said the vCloud Connector pane above is nothing more than a plug-in that is able to talk the standard vSphere APIs (to connect to vCenter instances) as well as vCloud APIs (to connect to vCloud Director based clouds). In fact, if I connect to the same URL using my web browser using the standard out-of-the-box vCloud Director UI, what I see is exactly the same thing... just in a slightly different layout. Here it is:

Note that I only have a local vSphere instance (vcenter.labvmware.com) and a single public cloud (vcd.stratogen.net/cloud/org/it20) connected in my vCloud Connector view. As I said before you can connect more vSphere infrastructures as well as additional clouds (private or public). Specifically you may be interested, as an IT department making its first steps into the cloud, to expand you datacenter into more than one public cloud provider. Doing so you will be able to see, in the vCloud Connector UI, all your local resources as well as all clouds where you have one or more Virtual Data Centers subscribed.

So now that we have everything in place (i.e. in the single pane) what can we do? If you haven't done so already I'd like to ask you again to read my other post on vCloud Connector to have the proper background on what it can do and what it cannot do as well as a background for the genesis of the tool in general. In short, what you can do are basic operations across instantiated workloads as well as templates on both vCloud based clouds as well as vCenter instances. I can't possibly show every single action with every single combination of public clouds, private clouds and vCenter instances. So, for the sake of keeping this post not too long (and bore you more than I am doing) I will just demonstrate an example of how the cloud consumer can benefit the most from our hybrid cloud story whose promise is about openness and flexibility. At VMware we usually pitch our hybrid cloud vision as the idea that you could move a workload from you private cloud into any vCloud based public cloud easily and transparently and taking it back into your private cloud when you want to, effectively avoiding lock-in.

For example you can move your vApp from your local private cloud to public cloud #1, then from public cloud #1 to public cloud #2 and then circle back moving the same vApp to your local private cloud again. Since vCloud Connector is really a bridge that vSphere users can use to move stuff into the cloud, other than the scenarios above, vCC also supports vSphere instances (not only vCloud based clouds).

Now that I have confused you, let's see how I can move a workload from vSphere into the Stratogen cloud. I have, for example, determined that a virtual machine running in my infrastructure is a good candidate for being moved and hosted into the Stratogen cloud. So what do I do? I just locate the VM in the vCC plug-in view clicking on the vSphere containers on the left hand side, right-click and "copy to". It's that easy.

Note that vCloud Connector doesn't "move" the VM. It copies it. That will leave the admin with the choice of either keeping the original VM or delete it (thus making it an actual "move"). Last but not least the VM needs to be powered off (sorry no vMotion - for the moment). I have decided to move into the cloud a desktop VM called VMW-SE-1 that is located on the local vSphere infrastructure in the Desktop folder. It's already powered off so I can right-click and "copy to" immediately:

Once I have done that, vCloud Connector asks me where I want to copy it to:

As you can see the plug-in offers me a drop down list of all the clouds and vSphere instances I have catalogued. Since I only have two and I am copying from the local vSphere instance I don't have much choices if not the Stratogen cloud. I have to choose then the Virtual Data Center where I want to copy this workload (again I only have one so not a lot of choices) and also the target network where I want to attach this VM once it is copied over to the Stratogen public cloud. Here I have three options and they are, obviously, all the network that are currently defined within my organization at Stratogen (see Episode 1: The On-Boarding for more information on this). The reason for which I need to choose a catalog is because, importing a vApp (or a VM) into the cloud, requires staging it in a catalog. I can then flag whether you want to keep the vApp in the catalog or you want to delete it. When I hit ok the process begin:

Note what happens at the bottom of the above screenshot. vCloud Connector is now exporting the VM in OVF format and it will import it into the Stratogen cloud. vCloud Connector leverages the export/import mechanisms (available in both vSphere and vCloud Director) that I have discussed in Episode 3: Moving vSphere Workloads into the Cloud.

When vCloud Connector is done I can see the new vApp available in the Stratogen Virtual Data Center within the same vCloud Connector view:

Now it's my choice to delete the original VM on the vSphere infrastructure and turn this "copy" into a "move" or leave both there.

Now that we have moved/copied a workload to the cloud let's see how the other way around works. Let's say I have decided that a workload that I have previously deployed in the cloud (the HRApp vApp in my example) needs to be brought inside my datacenter, on the local vSphere infrastructure. I locate the vApp in my Virtual Data Center at Stratogen, right-click and "copy to":

This opens up again the copy window that, this time, looks like this:

As you can see I have chosen a vSphere infrastructure as a target for this copy. Note the parameters in this window are slightly different than the parameters in the "copy to" window when the target is an actual cloud (like in the previous example).

Once the copy is done I can find the HRApp in the vCloud Connector view under the vSphere infrastructure:

And since what I see in the picture above is really just a different view into my local vSphere infrastructure, as a further proof of that this is how the workload we have copied/move looks like in my typical vSphere "VM and Templates" view (the interface you use 10 hours a day if you are a VMware administrator):

This concludes the fourth episode. This post was not intended to do a technical deep dive into vCloud Connector but it was rather meant to give you an idea of how the end-user experience may be improved using a tool that can bridge what vSphere administrator do on a daily basis with some innovative ways to source compute capacity. We at VMware think that there shouldn't be a disconnect between managing multiple private and multiple public resources and vCloud Connector is the first step into that direction (aka the hybrid cloud). Of course we are not there yet but this is a journey and you have to start somewhere. We also think that users should be given a choice where to source their capacity. While I haven't explicitly showed this in this post, I hope you appreciated at this point that adding another cloud infrastructure in your vCloud Connector pane is only "a click of mouse" away. Isn't that cool?

Massimo (twitter.com/mreferre).