Michelle Laverick Music

 

The new version of vCloud Connector (vCC) was released just on the cusp of Christmas, which was very timely for me – as I’ve got to the point in the vCloud courseware. In case you haven’t come across vCC before – its main job is broker access to public cloud providers who are based on vSphere/vCloud Director – but it also allows you to connect multiple private clouds together. There’s really 4 different types of connection you can configure:

Here’s a quick summary of vCC function with the new 2.0 release

Feature	Core	Advanced
View, copy, move VMs and templates	Yes	Yes
User interface improvements	Yes	Yes
Transfer speed and reliability improvements	Yes	Yes
Cross-cloud search for VM or template by name	Yes	Yes
Automatic catalog synchronization across clouds	No	Yes
Migrate VM while maintaining IP and MAC addresses [VXLAN required]	No	Yes

For me the big new features are really “Content Sync” and “Stretched Deploy”. The first keeps your catalog your private vCloud Director build in synch with your catalog public vCloud Director – the second allows you deploy VMs in the public cloud but have them communicate to VMs in your private cloud.

You can download the latest version of vCC here: DOWNLOAD and documentation both online and in a offline format is available HERE. There’s three parts to the vCC – The UI, the Connector Server and Connector Node(s). The admin guide has this handy graphic that outlines the relationships:

As my private configuration calls for the easy ability to deploy to/from vSphere/vCloud I will deploy to vCC “Nodes”…

STOP!!!

There’s a tendency to gloss over these sorts of diagrams because, lets face it there are a bit dull sometimes. But it is useful to KNOW this especially if you embarking on vCC configuration with a 3rd party. Life is pretty much simple is you own all the pieces in the game, but as soon as you working with a 3rd party you need to know what you need from them, and what requirements are ideally suited to offer you (the consumer) the smoothest of experiences.

Firstly, encryption. All comms to the vCloud Connector Server on clear-text http UNTIL you enable SSL and either use a self-signed cert or replace with a fully-trusted. Secondly, all comms to the vCC Node are SSL by default, and use an untrusted comms. If your a Service Provider… you need one vCC Server and one vCC node – that’s the same if your a private consumer. What you need as the consumer to register your Service Provider is – the URL for the nodes – like https://vccnode.cloudsRUS.com – your Organization Name, UserID and Password. So where its public or private you need precisely ONE vCC node per resource location (vCloud Director and/or vSphere).

Finally, quiz your selected partner over versions used. If your on vCloud 5.1/vSphere5.1 using VMs that have a hardware-level of 9. You vCloud Provider could be running vCloud 1.5/vSphere4.1 using VMs that have a hardware-level 8. This could scupper your planned use of vCloud Director (because you might be running 2.0, and they might be running 1.5).  Even if your chosen provider is on vSphere5.1/vCloud5.1 given that vCloud Connector was released on the 21st Dec. Be careful they might not support it yet…

The UI of vCC can either be accessed by a web-browser (covered in the next post) or via the vSphere Client (covered in this process). The Connector Server is the central point of management, with the “node” being deployed either in either vSphere/vCloud Director – which helps with the transferring of VMs from location to another. As those transfers can become larger, there is a network resume feature in case there is an outrage during the transfer – it will be resumed once the network is available again. You only need one node per vCloud/vSphere instance as it is multi-tenant aware – that means you do not need a “node” instance for each and every Organization in vCD.

WARNING:

Double-check the supported web-browsers wtih vCC. I found my version of FireFox and IE were incompatible, making some webpages blank in the main admin pages of vCC Server and Connector. I found Google Chrome worked without an error

The vCloud Connector Setup Routine…

I chose to do the import directly into vSphere using the all-new vSphere Web-Client – rather than importing into vCloud Director (which is also a possibility – you add in a template to the catalog, deploy it – and make it accessible within an Organization using a destination NAT rule). After power on you can connect to its service page by the URL of http://vCC.corp.com:5480 – the default username/password for both appliances are admin/vmware.

1. Typically the first thing I do with any VMware Appliance is:

Set the Timezone (System, Time Zone)

Set the hostname (Network, Address)

Reset the admin password (Server, General)

and in the case of the vCC Connection Server input the vCloud license key.

2. I then repeat the same configuration (sans the licensing) part on the vCC Connector Node

It’s worth mentioning you might not need to do this – for example if your using vCC to transfer VMs from vSphere to public cloud provider – what you will need is the node details of the Service Provider. In my case I’m setting up a node to access my own private vCD instance from vSphere. What’s a bit wierd about this (this the inception bit that comes from just having a lab environment) is that very same vSphere environment is hosting the vCloud Director lab.

3. Then I needed to register the Connector Node with the location I was going to transfer stuff too – in my case I registered my connector with my vCloud Director instance using the URL https://mycloud.corp.com – I select to Ignore SSL certificates because none of my appliance use fully-trusted certificates. You can specify the name/IP address of your vCenter server (by selecting vSphere from the pull-down list). You might find that a little bit confusing the idea of a “Cloud Type” being “vSphere” after all vSphere on its own can’t be construed as a “cloud” in its own right.

Really the important thing here is not where the vCC Node runs, but the cloud type and URL – as this controls the resources it will be able to access.

4. Once a node is “registered” with a cloud type, then you can configure the vCC Server to access the node. This means logging into the vCC Server, and selecting the nodes tab, and clicking the “Register Node” tab.

Note: The “public” tick of box is used if the cloud provider is external to your company. In hindsight the name “CorpHQ Organization” was a poor name – and I changed it to Corp Private Cloud instead…

5. The vCC Server can register itself with vCenter – to allow easy access to the vCloud Resources – this option is held under the vCC ‘server’ tab, and the vSphere Client…

This registration process adds vCloud Director icon to the vSphere C# Client like so:

The icon is merely a pointer to a web-page, and as such is dependent on the web-browser security settings. If you your using Internet Explorer, the recommendation is to lower your security settings to “medium” for it to work without error messages.

6. Under “clouds” its possible to add in a cloud provider – using the green + symbol, and specifying the username/password for the Organization:

Important: The account you use here is significant – as its privileges will dictate what actions are possible. In my first configuration I used a vApp Author account (ddraper@corp.com). This was a mistake because when I tried to copy a vSphere Template into my private cloud I received an access denied – that’s because a vApp Author doesn’t have rights to add stuff to the vCloud Catalog…

Once completed this will allow you to see the Private Cloud, the Organization and the Virtual Datacenters and beyond…

After my rename – the UI was a bit neater…

7. Once configured – a vSphere user can browse the vCloud Director catalog, and deploy a vApp from there… In this case I select the cloud, the vApp Template, and the Deploy button:

8. Deploying and registering a vCC node proved to be so easy I decided to create anoter vCC node, and register it with my vSphere installation.

and I then registered the vCC Node with the vCC Server:

Once you have vCC Node for both vCloud and vSphere – then you can do things like selecting a template from vSphere and deploy into the vCloud environment….

10. Once the vCC is aware of the private vSphere implementation, you can add into the vCC plug-in the vSphere Client as we did previously with the private vCloud instance.

11. In the vCloud Connector plug-in select the vSphere template (in my case I selected the Oracle Linux template I have which has Oracle eXpress Edition pre-installed – we can then copy the template into vCloud Director’s catalog, and then deploy it once it has been uploaded – you also have the option to delete the template from the vCD catalog.

12. This allows you to select which cloud, catalog you want to deploy to… One thing you will notice when you do this deployment – is that you cannot control the storage location in this case vCC uses the default storage profile selected when the Virtual Datacenter was defined.

The vCloud Connector Install/Configuration guide has this useful graphic that shows you step-by-step what the relationships are:

1. Customer requests transfer using vCloud Connector UI.

2. vCloud Connector Server tells vCloud Connector Node to transfer vApp.

3. Node tells vCenter Server to “export” using VIM API.

4. Content is moved from datastores to source Node cache.

5. Content is transferred from source to destination Node using checkpoint-restart

6. Destination Node calls the VCD API to “import”.

7. Content transfers from destination Node cache to VCD transfer server storage.

8. VCD sends the command for the appropriate vCenter import.

9. Content transfers from VCD transfer server storage to destination datastore network and is made available through the VCD catalog.