vRealize Automation 6.2 is GA

speeddialLadies and gentlemen, start your downloads!

vRealize Automation 6.2 (formerly known as vCloud Automation Center) has gone GA today. Beside the usual raft of fixes, the major focus for this release is the integration with vRealize Operations 6.0 (formerly known as vCenter Operations Manager).

Download VMware vRealize Automation 6.2

Also updated to download are:

And finally, all new and shiny is vRealize Code Stream. This, I am really looking forward to as it’s aimed at providing continuous delivery of software releases. And that could include vCO (I mean vRealize Orchestrator) workflows – something I’m doing a lot of at the moment.


vCAC 6.1 goes GA

Ping! It’s baked and out of the oven at last. vCAC 6.1 has hit a download server near you.

I’ve been waiting for this for a while now, so what’s new? From my perspective some of the most interesting new bits are:

  • Tighter Puppet integration
  • Enhanced support for NSX (including the use of NSX / vCNS workflows as actions in the vCAC Advanced Service Designer) – I need to try this out!
  • vCenter Orchestrator plugin enabled scripting of entities including Catalog, Approvals, Entitlements, Advanced Service Designer etc (I’ve wanted this for a while now)
  • vCAC support for Windows Server 2012 SP1 R2 (.NET 4.5.1)

But there’s plenty more (see the Release Notes).


vCO “Plugin” for NSX

If you’re starting to get your hands dirty with NSX and want to automate some operations using vCenter Orchestrator (vCO), there’s now a plugin for it that’s been released into the community by Christophe Decanini (who writes on the vCOTeam blog and works for VMware).

It’s not a traditional plugin for vCenter Orchestrator in the same way that there are plugins for vCenter / vCAC / Infoblox etc. Instead it’s built on the Dynamic Types plugin that was launched with version 5.5 Update 1 of vCO.

The goal of the plugin is to create the ability to offer NSX “as-a-service” operations as catalog items within vCAC. The creation and manipulation of security groups and policies along with the ability to associate VMs with these objects can all be offered as options for users to select within the vCAC catalog using this plugin.

If you’re not using vCAC then the plugin could still be used within your own workflows.

The plugin was released on the VMware Communities site yesterday.


vCAC 5.2.1 Released

I missed this on Thursday. It slipped out quite quietly. However, VMware have now released version 5.2.1 of vCloud Automation Center.

Possibly the best way to view this release is as an update-rollup as it includes features and fixes introduced in each of the following Hotfixes to 5.2:

Also included are a few changes that seem to me to be aimed at closing a few gaps between 5.2 and 6.0.

As far as upgrades go, the upgrade path seems to be from 5.2 only or 5.2.1 can be installed from scratch. There are a couple of installation / upgrade gotchas to be aware of so it’s worth reading the release notes before planning an upgrade. I’ll be giving it a try in the next few days.

It’s not 100% clear if this will be the final release for vCAC in the 5.x branch. I’m thinking that it will very much depend on when VMware release a version of 6.x that supports upgrades from 5.x.


vCAC 5.2 – Accidental Deletion of a non-vCAC VM

It was tempting to call this article “vCAC Ate My VM” but it’s not a useful description of what it’s actually about.

I was onsite with a customer recently when an odd bit of behaviour occurred whilst testing some out some code in the BuildingMachine stub. I’ve reproduced what happened in my home lab and while it’s a bit worrying and probably a bug, I’d hesitate to ring the alarm bells too loudly.

A bit of scene setting is required to explain this first.

  • The customer wanted to use user specified machine names. The blueprints in use have been configured to request a machine name from the person requesting a VM.
  • This name is also used for the VM’s guest OS hostname during the customization of the VM. Understandably this has to be unique within the DNS zone / network being used.
  • The vCenter being used as a vCAC endpoint is the same one that “owns” the vCAC infrastructure and many other production VMs. However vCAC has it’s own cluster to consume resources from.

The customer wanted to ensure that users couldn’t request a VM name that was already in use. vCAC does its own checking to ensure that the same name is not used with vCAC itself. However, it does not check for existing VMs in vSphere. This is why I was adding some code to the WFStubBuildingMachine workflow.

The solution that I had was a simple piece of PowerCLI that connected to the vCenter server, checked to see if the requested VM name was in use in any of the other clusters and failed the request if it was. Fairly simple and it worked. What I saw however was that the existing VM was destroyed by vCAC. Luckily it was a test one and not a production one. However, given that the vCenter server also managed non-vCAC VMs, this was a bit worrying and why I have been investigating it in my lab.

To reproduce the issue, I needed two clusters in my homelab (which I already had):


One for management VMs and one resource cluster for vCAC to provision into.

I created a simple VM from a vSphere template called “testvm” in my MGMT cluster that would be my guinea pig. I then built a quick vCAC 5.2 server and configured my vCenter server’s “RES” cluster as a Compute Resource. With a reservation in place and a simple blueprint I was ready to test.


Having verified that I could create VMs via vCAC with custom names successfully, I then went about customising the WFStubBuildingMachine workflow so that it would exit in a “Failed” state. Adam Bohle has a posting that explains how to accomplish this, I simplified it a bit as I didn’t need all of the logic in place, just a failure.

Using the vCAC Designer, I simply added a step to return a Failed state from WFStubBuildingMachine and sent the change back to the Model Manager.



After another quick test, I could see that as soon as any request hit the “Building Machine” stage, it failed and vCAC would dispose of the VM. The important thing to realise is that in the lifecycle of a vCAC machine, “Building Machine” means that nothing has been created yet outside of vCAC. No cloning in vSphere has taken place. So disposing of a failed request at this stage should not really involve vCenter at all.

Now the real test…

This time I made a vCAC request for a VM called “testvm” (remember that it’s in my MGMT cluster and vCAC is set to use only my RES cluster for VMs).


As expected, the requests fails at the “Building Machine” stage and vCAC disposes of the VM.



Back in vCenter “testvm” is still there and running ok. This is good. As I’d hoped, vCAC doesn’t touch something that’s in another cluster.

If the “testvm” machine is moved to the RES cluster though, what then? Boom! vCAC jumps into a Disposing stage as expected but deletes the non-vCAC VM from vCenter that has the same name!


Whilst this probably shouldn’t happen, what I was doing here wasn’t good practice anyway. The cluster that vCAC provisions into should only be used by vCAC. There should be no other VMs in there at all.


vCAC 6.0.1 Released

Sometime late last night, VMware popped version 6.0.1 of vCloud Automation Center on to their download site.


This is a maintenance release designed to fix a few of the issues that exist within the 6.0 GA version of vCAC. They’re too numerous to list here but there are a handful that are relevant to my current project and my home lab setup. However, I won’t be installing it straight away.

Known Issues

Before embarking on an upgrade, read the release notes CAREFULLY! There are quite a number of known issues that will bite you if you’re not prepared for them. For instance, the upgrade will revert vCAC to use the internal vCO instance rather than the external one if you’ve configured that. Also, .NET 4.5.1 is still not supported. Be warned, there are many more.


If you’re already running vCAC 6.0 then there is a supported upgrade path. The bad news for anyone using 5.x is that upgrades to 6.x are still not available. That functionality is still penciled in for a future version.


vCAC 6.0 Announced

vCAC 6.0 was announced in Tuesday’s General Session and it’s expected to be generally available in mid-November 2013. For me, this is the most exciting announcement to come out of VMworld Europe. It’s all about building, deploying and managing application catalogs.

VMware acquired DynamicOps in mid-2012 and managed to rebrand and launch it as vCloud Automation Center 5.1 at VMworld last year. There has since been a 5.2 release but 6.0 includes some very significant changes. Two of the biggest are:


vCAC installation has historically been a bit of a pig. 5.2 has its own pre-requisite checker and a number of hoops to jump through to get it up and running. Jonathan Medd even recently produced a superb PowerShell script to automate the setup of the pre-requisites.

With 6.0 however, vCAC is being partially released as a virtual appliance by being broken down into several components. The IaaS (.NET) core is still hosted on Windows but the Self-Service portal and Application Director (see below) components are virtual appliances. The portal appliance includes a full instance of vCO.

On the face of it, deploying vCAC may seem more involved but having some key functionality hosted in virtual appliances is a sensible move in my opinion.

Say Hello to Application Director

There is now going to be greater integration with (vFabric) Application Director and the latter will actually be bundled with vCAC 6.0 although it will be distributed as a separate appliance. The point of this is to allow organisations to define and build applications (blueprints) in Application Director and then manage deployment and infrastructure through vCAC.

There’s a lab available in the Hands-on-Labs that showcases the vCAC 6.0 beta. Try it out.