With the lab upgrade complete it was time for some new service deployment in support of my hybrid cloud scenario testing aspirations.  I had a look at various 3rd party hybrid options, (OpenStack, Eucalyptus, Hotlink, etc), but while all are interesting in their own ways, I decided that a native approach would be the most valuable scenario to test first.  By native I mean utilizing VMware first party tooling, in this case vCloud Automation Center and vCenter Orchestrator, to achieve on-prem ITSM automation and then extending that architecture to AWS by directly calling the AWS APIs.  A good combination is to utilize vCAC to provide end-user facing self service portal capabilities (presenting a rudimentary service catalogue) and then, as part of the machine provisioning cycle which follows, utilizing vCO workflows for the deployment automation.  There are some limitations to this approach, and some tools overlap, that I would like to explore in more detail as I think it is an area of critical importance to many IT shops which could use more prescriptive guidance.  The final architecture would look something like this:

The first step is to download vCloud Director.  It is pretty straightforward to do this once you have a VMware account created.  In order to get access you request an evaluation and then download the OVA.  In addition to vCD, I also downloaded the vShield OVA as I plan to test both vShield app and edge within my hybrid environment.  Interesting that both are packaged as OVA only (at least as far as I could tell from my download entitlement page) at this point.  It is possible that installers are still available.  My buddy Kendrick Coleman, VMware guru extraordinaire, suffered through the 9000 page manual install of this and, while I’m big on solidarity, I doubt it’s something I’d actually want to put myself through.  That said,  I am going to ask around a bit and try to get an answer on that, but in the meantime OVAs are normally the path of least resistance anyhow and should be great (as long as everything works as intended!).  The downloads are 1.4GB each so plan accordingly.

With the bits in hand, the first step is to install the OVA.  This is basic stuff, but just as a refresher:

Some notes on the sequence above:

• vCD uses two network interfaces and, as a best practice, they really should be attached to different vSwitches.  One network is for UI/API access to the vCloud service, the other is the network which will be utilized for console access to vCD created guests.  Since I only have a single physical NIC in each host, much like with management traffic, I don’t bother segregating VM traffic into discrete vSwitches (it’s all going the same place anyway).  I may change this just for the sake of accuracy and document the process in a future entry
• By default vCD will install a local, internal, database, but can also be configured for external database access if desired.  I try to keep these installations self contained (especially an OVA), so I keep the databases local.  If you are doing management database consolidation, this is where it would be configured
• A number of components will be installed (JRE, web server, etc), but the OVA installation was quick and painless

Once installed, it is time to test that our new vCD is up.  Let’s fire up Chrome and connect to the IP assigned for UI/API access:

Uh oh!  Well that’s unfortunate.  Time to fire up Firefox (I knew there was a reason to keep that around!):

Ah, much better!  So the OVA install was successful and vCD is officially up and running.  Lets go through the initial configuration:

Nothing complex here and so far the experience is great now that we have an OVA.  Accept the agreement, apply a license (not shown), create an admin account and profile and name the vCD system.  With those four steps complete the next stop is the vCD login screen:

Logging in we are presented with the initial vCD configuration screen where we can configure our provider resources and create our first organization:

First we attach our vCenter.  In my case there is only one, but obviously in a multi-vCenter scenario the one to enter would be the one that will be providing resources for the vCloud:

This is a good time to validate a few things about your vCenter.  The key areas to focus on are:

• Connectivity – pretty obvious, but make sure the vCenter is online and available.  This includes making sure that DNS is well sorted out.  It’s a good opportunity to make sure there are no lingering issues with vCenter internally and that it is available, by name, from both its hosts and from the vCloud OVA.
• Identity Management – another obvious one, but it is also a good time to make sure that AD is healthy and that all required users are in place and can login (admin account, service accounts, etc).  vCenter 5 introduces the SSO as a handy point of federation, but it also makes identity management just a bit more complex.  Verify that the IAM infrastructure is healthy before moving forward.
• Resources – have a resource plan.  At this point you should know which resources (hosts, storage, network) that you are planning to allocate to the vCloud.  Make sure that the host configuration is where you want it to be.

Essentially, the theme here is to have a functional, well rationalized, and clean vCenter environment before adding vCloud to the mix.  Even for a lab, possibly especially in a lab, I think this is a good practice.  vCloud inevitably introduces complexity right at the core and it is no fun to add that complexity into an environment with lingering problems (ask me how I know!)

If everything is in order, the vCenter attach will proceed with no issues.  If it breaks, the first places to look will be the points above.  With the vCenter config complete, the next step is:

Oooooh right.  vShield Manager.  I knew I forgot something!  vShield is the virtual security services facility and is a critical part of an enterprise virtual architecture; particularly in a cloud utility context.  vShield provides security services both at the hypervisor level, where it creates a secure wrapper around specific VMs (vShield App), and at the network edge (vShield Edge), acting as a virtual stateful firewall providing NAT, DHCP and filtering services (deployed as a virtual appliance).  Since vShield can be orchestrated via API, it can be integrated into a broader strategy for automating complex deployments (critical for a cloud style service).  OK, all of this sounds good, so let’s pause the vCloud config and go ahead and install the vShield Manager OVA (the other 1GB plus download that came along with vCD):

Standard OVA install stuff here.  Pretty painless to install vShield Manager.  I didn’t go ahead and configure any actual vShield constructs at this point, I mainly just wanted to make sure the core infrastructure was online.   Once the OVA is in place, we can connect to the web interface for the final configuration.  By default the OVA will grab an IP from DHCP (assuming DHCP is available which is definitely recommended for initial setup).  Connect to that IP and login using the default credentials: login: admin password: default

Worth noting that these shiny new VMWare web UIs are Flash (boo hiss!!!), so plan accordingly.  After logging in, there are some basic things to set up in order to get vShield Manager ready:

 

First up, change the password.  It’s pretty awkward if one of your core security facilities is running on default passwords – even in a lab!  Next step is to connect to the vCenter to which vShield services are being introduced.  Once again, if vCenter is healthy this is straightforward.  There is also an opportunity here to make the vCenter admin account the vShield admin.  This is what I did for simplicity in the lab, but of course in production scenarios it is quite likely that this would not be the case and that a specific vShield administrator would be created and assigned.  If vCenter is using a local cert, the install will warn about authenticity and ask for confirmation of trust.

With vCenter configured the next step is to configure the Lookup Service.  This is a vCenter SSO component new with 5.1 and we need to enter the URL, TCP port and admin creds in order to register vShield Manager.  As with vCenter, there will be a request to confirm trust if local certs are in use.  With the configuration complete the management console should show vCenter detail in the left panel:

That’s it for the vShield Manager intermission and probably a good place to pause!  Coming up next, vCD configuration continues!