In my previous post on this topic I setup the vCloud Connector (vCC) to allow my vSphere users to deploy vApps to my private vCloud Director installation. I’m going to ASSUME that the setup there you have already done. Otherwise this blogpost would become quite a length repeat of that post………
In this post I want to go in the opposite direction – connecting my private vSphere/vCloud environment to a public vCloud Service Provider. Before I began I knew this was going to be somewhat of tall order. I’m using vCloud Connector 2.0 which was released on 21st Dec, 2012… At the time of writing the draft of this (12th Jan..) that’s only weeks ago, and then there’s been the holidays – so the chances of any of the Service Providers upgrading during this period is slim…. So I knew I would have to use some of personal contacts in the industry to make this happen.
The best place to find a public vCloud provider for your home lab is using vcloud.vmware.com website. You can apply filter to show just the providers who offer a “Test Drive” in your region. I opted to sign up for a test drive with iLand, as I’ve had on them on chinwag a couple of times, and have local contacts – so I figured if I got stuck I could call on those personal contacts. It’s also handy that they have 30-day eval. At the same time I also signed up Stratogen for much the same reason. The Stratogen folks have been on the chinwag before, and I have contacts in London with them…
Before you go any futher – let’s have a look at the requirements for vCC.
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 you’re a private consumer. What you need as the consummer 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…
As the “consumer” what you need is an account with the service provider – (userid/password). After login if they expose the vCloud Connector UI its dead easy to find out your Organization Name – if the SP has written a shell around vCD using the APIs – then you might need to ask them what your Organization Name is – finally, you need the HTTPS URL for their vCloud Connector Node residing registered in their public cloud with their vCloud Connector configuration.
What follows below is more detailed description of what I did with each Service Provider… Before I go any further I want to be 100% honest with you. I worked very closely with the various providers (iLand and Stratogen) who have long-standing relationship before I even joined VMware. They have worked very hard (Simon Greaves of Stratogen and Justin Giardina of iLand.com need to be bought a big pint of beer!) to make this happen. vCloud Connector 2.0 is quite new on the block, and doubt very much if EVERY SINGLE one of our vCloud Service Providers is ready to support it.
One tip I would give is this – some vCloud Service Providers brand the vCD UI pretty heavily, others leave you with the portal as is – once you have 4 vCloud Director webpages up (Stratogen, Iland, VMware Hybrid Cloud and your own) it is VERY easy to get lost. For example in my haste I upload a copy of Damn Small Linux to the VMware Hybrid Cloud when I intended it to go to my Private Cloud. I was having one of those off days where Murphy’s Law was at play (grrr! Java!). So… do yourself a favour. In your Org head off >>Administration >>General and change your “Organization Full Name”
Stratogen and vCloud Connector:
I’ve known the guys at Stratogen for a while – Karl Robinson was one of my very early “vendorwags” back in my RTFM Education days – we often see Karl and the Stratogen folks at the London VMUG, and I recalled they helped my colleague Massimo Re Ferre get started with the vCC 1.0 version sometime ago. One you have your vCloud Connector Server up and running, it simply a matter of login into it, and adding in your vCloud Service Providers details under the Nodes tab. Remember what you need from them are the following details:
- URL to their vCC “node” expressed in the https:// format
- You vCD OrgName – you maybe able to find this out from the login details they gave you when you signed up to their service
- Username/Password – usually the same as those used to access your vCloud Director portal
1. Under the “Nodes” tab click the “Register Node: button
2. In the Register Node dialog box complete the form using the variable garnered from your vCloud Service Provider. In my case I’ve entered bogus information in the dialog box. But I think it far to say that often I’ve found vCloud Service Providers make the “vCD Org Name” the same as the Username.
Note: The option “Public” indicates that this is a public cloud vendor rather than private, and it will show up this status in the vCloud Connector plug-in to vSphere.