TAG: vcac

vCAC 6.0.1 Plugin for vCO

Very very quietly, VMware has GA’d its vCAC 6.0.1 Plugin for vCO. Why is this plugin so important? Well, since the plugin shipped with vCAC’s vCO server in the 6.0.1 virtual appliance is a revolution / update of its 5.2 plugin brother (interfacing with vCAC’s IaaS ODATA API) this plugin includes both the IaaS plugin AND a new set of capabilities to interface with the vCAC VA APIs! This means that the ability to create service catalogs, tenants, catalog items, and much much more, is now available for everyone, with ease.

Part of the work I did in my vCAC DevOps Post, relied on the capabilities of this plugin. (which was in pre-beta , early milestone phases) So, although the vCAC 6.0.1 API is considered to be ‘Beta’ this plugin supports it. It enables us to do some very interesting stuff, such as requesting a Catalog Items, customizing item requests (more on that in very very near blog posts!) and more. The thing that’s great about having such a plugin, is that it enables the IT administrator and the developers (or the cloud customer/consumer) to radically abstract the vCAC API, and use only the functionality needed, with great simplicity.

If you want to integrate with another system calling vCAC, you can share the coding load by masking very complicated tasks like requesting multi machine blueprints, in a very simple fashion using vCO – vCAC Plugin workflows, and later on, exposing the specific functionality using vCO’s REST API.

Overview & Install

This plugin lets us work with every aspect of the vCAC VA application platform, like:

  • Approval Policies
  • Advanced Service Designer
  • Service Catalogs
  • Catalog Items
  • Item Requests
  • Actions (Day 2 operations)
  • Entitlements

In order to install the plugin, simply go to the configuration page for you vCO server, browse to the download o11nplugin-vcac-6.0.1.vmoapp file, enter administrator credentials, and choose ‘Install plugin’. You will have to restart you vCO server afterward (just the services).
If you are using vCAC’s VA vCO Server , you’ll need to enable the vco-configurator service by logging in to the vCAC-VA and entering these commands:

[code lang=”bash”]
chkconfig vco-configurator on
service vco-configurator start


To configure the plugin, run the configuration workflow found in the vCloud Automation Center folder inside vCO, with the appropriate parameters:
Config VCO Plugin

The OOTB workflows for this plugin are pretty handy, giving us the ability to do some common tasks with the objects mentioned in the points above, like copy/create/delete a service, request a catalog item, trigger resource item actions.
But what’s actually underneath the hood, is way more interesting…

An object very worth mentioning is the vCACCAFEEntitiesFinder object. This scripting object is always available to us, and has some very useful methods for us to use in scriptable tasks and custom actions.

It’s fairly easy to understand why I’ve designed this post’s logo the way I did…
In any case, one very important methods to notice is:


This important piece of API can be seen in action in one of the sample workflows shipped with this plugin called ‘List Catalog Items’
Lets analyze the scriptable code for this workflow.

[code lang=”js”]
var items;
if (criteria == ""){
} else {
items=vCACCAFEEntitiesFinder.findCatalogItems(host, criteria);

System.log("Total elements: " + items.length);

System.log("Catalog items:");

for (var i = 0; i<items.length;i++ ){
System.log("   " + (i+1) + ".    " + items[i].getName());


We can see that the entity finder finds us all of the catalog items in case we didn’t enter any search criteria, but in case we’ve searched for a specific item (by name) we will get an array of catalog items matching that name (or close to that name).
then, we have the vCAC Catalog item object, and we can act upon it. Pretty straight forward stuff!
I’ll example more of this vCO Plugin’s capabilities in later posts, so stay tuned!

Enabling DevOps using vCAC 6

Its been a long time since I last wrote a post, unfortunately (or fortunately, i’ll admit) i’ve been working frantically on a very special use case for vCAC 6, using it to demonstrate DevOps scenario.
In this scenario, vCAC will be used as an IaaS platform to let Jenkins deploy a full continuous integration process. Building code, deploying it on a Multi Machine environment (a customer’s requirement). And generating a new build for QE to test.

In order to build this, I used some of the principles demonstrated in my previous article , writing a short code activity for a part of the implementation, while also using a new vCO plugin that isn’t released yet, and is actually in pre-beta phases.

The general description of this very interesting use case, goes like this:
1 – Jenkins requests vCAC to provide with clean ‘vanilla’ IaaS environment from vCAC 6, with REST API calls.
2 – vCAC then deploys , and runs a puppet command to install a CI night build on the VMs in the MultiMachine environment, as an “On” state workflow
3 – Jenkins executes a Multi Machine custom action – ‘Clone To Catalog’ after install is done, through vCAC API.
4 – VMs are cloned , blueprints are created, a new catalog item is created in ‘Night builds’ service
5 – Jenkins executes a final command, massively requesting the new catalog item for sleeping QE personnel so when they arrive to work at morning, they have a new environment ready for QA testing.

I believe a lot of organisations should adjust their development cycles to be efficient. This results in faster then ever time to market, and software versions being rapidly developed. 
DevOps is real, and cloud, is definitely the answer for it.

This is also a great example of utilizing the vCAC 6 APIs (which are currently in beta state) and maximizing the use of VMware’s main cloud solution.

Check out the demonstration video I made below, and be sure to leave any comments in the comment section!

Architecting a Distributed vCAC Cloud

In order to install a multiple VM vCAC cloud, one must first need to get to know all of the vCAC components. Lets overview:

vCAC Database

The actual DB Server, (Microsoft SQL in our case) contains all of the inventory data on the existing endpoints, contains the AZMan store for maintaining each user’s role and permissions (if you chose to set it up in as an MSSQL store of course). Also, the database holds one interesting table, with all types of policy workflows that can (and can’t) be loaded and edited on the vCAC designer.

HA Considerations: vCAC DB Could be set up as an MS SQL MSCS Cluster. Although, personally I’m not a big fan of MSCS on my virtual infrastructure ( thus, any infrastructure, as physical servers are not an option ;) )

vCAC Manager Service & DEM Orchestrator

The vCAC Manager Service is the service responsible for all of the connections between the vCAC components (Website, Agents, DB, SMTP).
So overall, its an important part of the system.
The DEM Orchestrator, is the component that actually orders each DEM Workers to run which workflows, according to Skill tags, or if several DEMs are involved.

HA Considerations: As both of these components are pretty crucial to the system working properly, you might want to set it up in HA mode, which is Active/Passive solution today. Of course, it all depends on the use case and HA requirements. Also, for this to work, you should put both of the servers set up in HA behind a load balancer.

Model Manager Data & Web

The model manager role actually refers to two types of data. One is the “Model Manager Data” and the other being  the actual vcac website, also named “Model Manager Web”.
The model manager data installation, actually installs all of the data structures that vCAC uses to manage different endpoints and workflows into the database (thus only has to be installed once in a web-server scale-out scenario)
The model manager web installation, installs the required web data for that web server running the vCAC portal / self-service portal / reporting website.

HA Consideration: If servicing a lot of users, and you want to make it scale, you should probably install these components behind a load-balancer.

vCAC DEM Worker / Agent

The vCAC DEM worker is the component required to to execute actual vCAC workflows like:
– Data collection from different endpoints
– Executing provisioning workflows to certain endpoints
– Executing all of the actual stub and non-stub workflows during the different states of the machine request

The vCAC Agents are actually somewhat of equivalent to DEMs but handle certain types of endpoint like vSphere endpoint, Hyper-V and KVM.

HA Considerations: vCAC DEM workers can actually be installed in several instances, thus allowing the DEM Orchestrator to order different DEMs to do different types of work.

HA Consideration: Well, this one depends on scale, and on amount of workflows you run. Each DEM worker, will actually only run up to 15 workflows at a time, while queuing the others. While this sounds like a big number, one should keep in mind that apart from provisioning workflows, the vCAC system will also perform a lot of scheduled system workflows to perform various tasks , such as keeping track of endpoint inventory, and more. So in this case, installing more than one DEM in an environment could prove quite useful, and help the environment perform more operations.

Architecture Examples

Here are some architecture examples that can be used for several environment scenarios

This is a fairly straight forward example of installing vCAC 5.2 in a medium environment, to support Dev / Test provisioning . According to vCAC Reference Architecture Guide, this environment size should fit above 1000 VMs.
Another, more robust example of vCAC architecture, is the one for production use cases:
Production vCACNotice, that here, the vSphere agent is shown in a different manner, because I’ve tried to represent a different design approach for it,  installing it on the vCenter itself. Thus constraining the vSphere agent’s availability and vSphere provisioning as a whole , with the availability of vCenter itself. which makes a lot of sense in many use cases where vCenter is a VM relying on vSphere HA.

Distributed installs ‘Gotchas’

When installing vCAC 5.2 in a distributed manner, you should look out for the following specific “Gotcha’s”

  • When using self-signed certificates, you must import the certificate from the manager server, and the management model , to every other component in the vCAC environment that will access them via 443, meaning : DEMs , vSphere Agents, and also Model Manager Web server to the Manager Server. Everyone, needs to trust pretty much everyone else :)
  • When deploying an environment where the web servers reside behind a load balancer, use sticky sessions on the load-balancer. Other wise, you will have to deploy the servers in “Web Farm” mode, which requires for an additional database to handle the users sessions and keep track of it. This degrades performance.
  • As always, use the pre-requisites checker to make sure that all of the parts and pieces needed for the system install on each server are in place. Check the right hand menu in the Pre-req application, to make sure you selected the right components to be installed on the system.
  • DEM workers, need nothing but secondary logon service turned on, and a firewall to be switched off. So nothing to prepare in that case

Hit the comment section for any questions, i’m a quick replier. Also, be ready for the same article recreated for a vCAC 6.0 deployment after it’s GA :).

vCAC 5.2 Icon Pack

Here’s a small something for you guys using vCAC 5.2. I’ve created an icon pack with a consistent design of icons (picked up and edited from the net) for you to use on your vCAC 5.2 deployment. As I see it, “The Cloud” should be a fun thing to use, and also something that the user actually wants to use.

In that context, eye candies are always an awesome solution! so hit the vCAC icon pack download button below, and if you have any more ideas / icon requests i’ll be glad to help :) Hit the comment section, or tweet me @elastic_skies

vCAC 5.2 Icon Pack

Creating & Running vCAC Workflows, in an “On” State

One of the things that I like about vCAC , is the ability to run workflows in each different stage of the machine provisioning. This enables us to do a lot of the manual work that usually occurs when a machine is requested in our organisation , automatically with vCAC workflows. In order to take advantage of the full vCAC workflow capabilities, we will need a CDK license for our vCAC instance. “CDK” is actually an acronym for “Cloud Development Kit”.

What the CDK actually does is allow us to upload new workflows to the database, using the cloudutil.exe utility, installed when we install it and the vCAC Designer. Also, it will install a Visual Studio plugin for us, allowing us to easily create new xaml files (Microsoft’s .Net Workflow file format) with all the stuff we need to run in vCAC. The installation is fairly simple (Just remember to put the vCAC Web Server FQDN name, and the 443 port ), so I’ll jump to the more important stuff.

Before we get started, I must say I know there are quite a bit of “how to create a custom workflow” posts, but I posted this with the intent of showing some interesting fact I found regarding an “On” state workflow specifically. Lets get started!

To create a new workflow, we will open Visual Studio (needs to be 2010/2012) and create a new project

The new project should be of a type C# workflow, as seen on the right pane, and I usually choose activity library, which is simply an empty workflow file.

vCAC WF Generator

Now, we will click the vCAC Workflow Generator from the tool menu. If you’re seeing it as greyed out, just click the Add-In Manager, uncheck the tool, and try to select it once more from the tool menu.

vCAC Workflow Generator

After that, we’ll see the workflow menu popping up. Here, we’ll click the two “Add” buttons, in order to generate a new workflow xaml file in our project, and also so we can add the necessary references from vCAC dll’s so we could use the vCAC CDK activities.

our second menu will require us to enter a workflow name, and type. Yes I named mine “AppDeployMonitoringAgent” as a hint to what will this workflow do. Generally, naming workflows with good names is a real best practice, as things get complicated once we run a lot of custom workflows. The workflow is a “StateChange” workflow, since it will activate once a machine’s state had been changed to an “On” state.

Also, I’ve put a good Custom Property name as indication that the workflow should run. “App.Deploy.MonitoringAgent”.

Next step is to grab the workflow files from the project’s folder, and do the following:

1. External-<Name of workflow>.xml

– Put this file in the vCAC Manager Server, at: <vCAC Install Directory>\Server\ExternalWorkflows\xmldb

Example: C:\Program files (x86)\VMware\vCAC\Server\ExternalWorkflows\xmldb

Attention! –  In order to run an “On” state workflow, you need to edit the file , and replace the


from “On” , to “^On$”. Why? Well, vCAC will catch the machine’s state with RegEx, so by catching the phrase “On” we’re actually running the workflow at “InitialpowerOn” and “TurningOn” states as well… This could lead to unwanted workflow results. The replaced value will make sure that the workflow will run only once the machine is up and running.

After replacing the value, and putting the file in the xmldb folder, you should restart the vCAC Manager Service.

2. <Name of Workflow>.xaml

– Grab the file from the project’s folder, and put it somwhere it would be easily accessible from command line.

– Open a command prompt and navigate to <vCAC install folder>\DesignCenter

– We will use the cloudutil.exe file (AKA “vCAC Designer”) to enter the command:

[powershell]cloudutil.exe workflow-install -f workflowfilename.xaml -n workflowname[/powershell]

A good install would look like this:

That’s it, you’ve now installed a new workflow in the vCAC Repository and can access it from the “Load” button in the designer. We can now edit the workflow to do whatever we want, usually it’s going to be some powershell activity in an “On” state. But, I’ve got even more interesting scenarios for this machine state than you think. Find out in my next post!

BTW, do not forget to add the custom property you gave your workflow in the desired blueprint.