Integrate vCO


New OVF Transfer Plugin for vCO released

At the beginning of the Week I was pleased to place a new Plugin for the VMware vCenter Orchestrator in the VMware Solution Exchange ( ). The Plugin is called VMware Orchestrator OVF Transfer Plug-In and can be used to Up- and Download ovf Files with the VMware vCenter Orchestrator. Here is the description of the Plugin:
The OVF Transfer plug-in allows you to up and download OVF Templates to/from the vCenter via the vCO.
• The following operations are possible:
• Automatic deployment of your OVF templates
• Automatic export of VMs to an OVF

And some highlights:
• Upload OVF Templates via vCenter Orchestrator
• Download OVF Templates via vCenter Orchestrator
• As Source and Destinations the following places are available: Local file, HTTP, HTTPS and FTP. With the Windows installable version you can also use File share (CIFS)
You can download the Plugin from the VMware Solution Exchange here:

Many thanks to my colleague Carsten Schaefer who wrote and maintains the Plugin!


Backup vCloud Director vApps automatically, driven by vCO

This video shows another example how powerful vCenter Orchestrator really is:

Auto-Create a new Backup Job, whenever a new vApp is deployed in vCloud Director

vCloud Director Backup driven by vCenter Orchestrator from Joerg Lew on Vimeo.

For that I used the AMQP-Plugin, so that the “Create VM“-Event in vCD triggers the Generate Backup Job-Workflow. This workflow calls out to a Powershell-Script to create a new Backup Job using the vendor’s snapin. I used Veeam Backup&Recovery, because they provide a lot of helpful Cmdlets to automate their backup solution.

What to learn?

  • For vCloud Administrators: vCO allows you to integrate vCD with the rest of your IT-world
  • For Backup Vendors: Provide a Plugin for vCO (or at least a basic API), and your customer can integrate your backup product with the rest of their IT-world.
    (Then you don’t even have to develop the integration for vCloud Director from scratch 😉 )
  • For every VMware User: Even without vCloud Director you can use vCO for a lot of cool stuff to integrate your IT-world (what about to create a new Backup Job whenever anybody deploys a Template in vCenter…?)
  • For all: Be creative! Everything is possible with vCO!

References (in case I kicked your mind :mrgreen:)


vCO, SNMP Traps and vCOPS

Today I had the request, to generate a vCOPS Demo with an vCO integration. For that, I had a first look on Jörg’s post about is “Self-Healing datacenter” which can be found here:

For me, that was a good starting point but I want to integrate the SNMP Trap with an existing workflow. The creation of a Workflow to deal with snmp traps is not a big problem. The bigger problem is the “automatic” processing via Policy’s because there is no documentation (or I didn’t find it) . So I started to talk with Jörg and made some research in the web.  There I found this excellent post from William Lam about “Automatically Securing Virtual Machines Using vCenter Orchestrator”

This post from William (and his package) has everything inside we need.

First we have to create the preconditions like the SNMP installation in the vCO and the configuration in the vCOPS and the vCO. Jörg has this already documented here: so I will not repeat this steps here.

Let’s start with the Workflow development. First, we have to create a new workflow. I will call it “Execute Host Maintenance after trap” and I insert the following description “Waits to receive an SNMP trap from a vCenter Server instance, then set the host in maintenance mode or exist the maintenance mode “

After we created the Workflow, we go to the “Schema” tab

Here we insert some Elements. We need:

  • One Scriptable Task
  • One Decsion
  • The Workflow Enter Maintenance Mode
  • The Workflow Exit Maintenance Mode
  • And a Workflow End.

When you are ready your order should look like mine.

Now, let’s start with the Scriptable Task. I name it “Retrieve Host”. We want to extract the information out of the SNMP Message, for that we need some variables and SNMP Trap information. Let’s start with the SNMP Trap Information. The SNMP Messages comes with OID Numbers. Each OID Number has a different meaning and stands for a other component or message. The values of this OID Number can be found in the SNMP MIB Files which can be downloaded from the VMware Website. Every trap data has more than one OID Number



type: Number

snmp type: Timeticks

value: 1743301911

Element 2:



type: String

snmp type: OID


Element 3:



type: String

snmp type: Octet String

value: localhost

Element 4:



type: String

snmp type: Octet String


Element 5:



type: String

snmp type: Octet String

value: Resource

Element 6:



type: String

snmp type: Octet String

value: 1346068003943

Element 7:



type: String

snmp type: Octet String

value: Critical

Element 8:



type: String

snmp type: Octet String

value: New alert by id 36 is generated at Mon Aug 27 11:46:43 UTC 2012; Root Cause : (2 SYMPTOMS)

1. MESSAGE EVENT    (1 OF 3)

33% - FAULT -


Element 9:



type: String

snmp type: Octet String


Element 10:



type: Number

snmp type: Integer

value: 36

Element 11:



type: String

snmp type: Octet String

value: Verbindungsstatus der physischen Netzwerkkarte vmnic1 ist nicht bereit.

Element 12:



type: String

snmp type: Octet String

value: Health

Element 13:



type: String

snmp type: Octet String

value: Faults

For us, we want to search for the OID Number of the hostname and the error Message.

With this background information, we can create our needed In- and Outputs for our Workflow.

Local Parameter Variable Name Module Direction Type Value
trapData trapData Retrieve Host in Array/Properties
HostOID HostOID Retrieve Host in String
MessageOID MessageOID Retrieve Host in String
Host Host Retrieve Host out VC:HostSystem
SNMPMessage SNMPMessage Retrieve Host out String
NewAlert NewAlert Retrieve Host out Boolean

One important thing here: The trapData must be defined as Input Parameter not as attribute!

After we have created our variables, we can start with our scripting. I made a lot comments in the script, so everybody should understand what there happens….

// We extract the host name out of the SNMP TrapData
var HostName;
for (var x = 0; x < trapData.length; x++) {
var prop = trapData[x];
if (prop.get("oid") == HostOID) {
HostName = prop.get("value");

// We compare the extracted Hostname with the Hosts registred in the vCenter Server.
// when we hava a match, we have the managed object ID of the Host
var hosts = VcPlugin.getAllHostSystems();
for (var i = 0; i < trapData.length; i++) {
var tempHost = hosts[i];
if ( == HostName) {
Host = tempHost;

// We search for the OID in the Message to get the Field with the recieved error Message
var SNMPTrap;
for (var y = 0; y < trapData.length; y++) {
var prop = trapData[y];
if (prop.get("oid") == MessageOID) {
SNMPTrap = prop.get("value");

// Our search values in the Value Field of the Message
// When the Field contains the search string we beome the position. Otherwise be become a -1 value back.
var SNMPAlert = SNMPTrap.indexOf("New alert");
var SNMPCancel = SNMPTrap.indexOf("is cancelled");

// We check if the SNMP Trap has "New Alert" in the value field. Is so, we have a new alert.
if ( SNMPAlert != -1) {
NewAlert = true}
else {
NewAlert = false

Then we go to the Decsion. I name it “New Alert”. As Input we only need “NewAlert”. In the Decision field itself we set “NewAlert is true”.

After that, we go to the Enter Maintenance Mode. Here we only need to input variables:

Local Parameter Variable Name Module Direction Type Value
Host Host Enter Maintenance in VC:HostSystem
timeout timeout Enter Maintenance in number 0

Our Visual Binding has to look like this:

The same Variables and the same Visual Binding is required for Exit Maintenance Mode Workflow.

Local Parameter Variable Name Module Direction Type Value
Host Host Exit Maintenance in VC:HostSystem
timeout timeout Exit Maintenance in number 0

At last, we have to connect our Elements.  For the connections we Connect the start to “Retrieve Host” from there we connect the “New Alert”. From the “New Alert” we go with the Green line to “Enter Maintenance Mode” and with the red line to “Exit Maintenance Mode”.

Both Elements were connected to the End.

At last, we validate our Workflow and save our work.

After we have finished our Workflows, we create a Policy Template. For that, go to “policy Template” and create a folder with a name of your choice. I have a folder with the Name “”.

With a “right click” on the folder you can open a context menu and choose “ Add policy template..:”

First we have to insert a name and a description. I choose “SNMP Trap with data” as name.

Then we go to the Scripting tab

There we have to insert the Device from with we want to catch our data. You can insert the device by clicking on the first button.

In the Dialog we choose SNMP:SnmpDevice

Then we check the SNMP Device and then click on the Second button.

As trigger we choose “onTrap”

At last, we have to insert this Scripting in “Script” field from the “OnTrap” Trigger.

// Author Christian Strijbos ([email protected])
// based on Examples and a Blog Post of  William Lam
// SNMP Policy to Check for Host Maintenance in case of an host error

// Execute Host Maintenace after trap ID
// To catch the Workflow ID, just go to the Workflow, type CTRL-C, open Notepad and Type CTRL-V
// You will get the ID of the Workflow in the id. Field.
var wfId = "83808080808080808080808080808080AA8A808001345464207298aebf2a6a5a5";

// process SNMP trap
var key = event.getValue("key");
var snmpResult = SnmpService.retrievePolicyData(key);
var trapData = System.getModule("com.vmware.library.snmp").processSnmpResult(snmpResult);

// function to launch WF
function runWF(wfId,trapData) {
var workflowToLaunch = Server.getWorkflowWithId(wfId);
if (workflowToLaunch == null) {
throw "Workflow not found";
var workflowParameters = new Properties();
System.log("Launching Execute Host Maintenace after trap WF: " + wfId);
var wfToken = workflowToLaunch.execute(workflowParameters);

Some special notes here: In the Policy tab, variables are not highlighted. So if you write scripts on your own, make sure you write your variables well. Also there is no validation available, so there are a lot of possibility’s to make things go wrong 🙁

Save and close the template.

Next we want to apply out policy. Make a “right click” on the Policy Template and choose “Apply Policy..” in the Context menü.

In the menu you have to choose our SNMP Device

You can find your Policy under the “policy” Tab.

Right Click on it and choose “Edit”.

There you can choose our Startup Policy.  I choose “on Server Startup, start the Policy”. Save and  close the Policy.

At last, “right click” on the policy and start it.

After that, your policy is active and wait’s for SNMP traps from the vCOPS.

My setup follows the same principle like the integration with the SNMP Plugin with the vCenter Server like described in this Link:

35.8 KiB

LittleCMDB (An Orchestrator and WaveMaker project) – Part 7

Table of Content

In Part1 we start with the SQL DB Plugin and create the required database for our need.

In Part2 we start with the development of our Workflow. We will start with a few elements.

In Part3 we  finish the  collection of the VM information.

In Part4 we insert our data into the database and test our created workflow

In Part5 we create our webview to get a look on our Data in the SQL Database

In Part6 we will make our Workflow smarter to update the DB with actual VM information

In Part7 problems with vAPP located virtual machines are fixed


Today we will make some more error corrections for our LittleCMDB. Has anyone build the LittleCMDB yet? Do you use vAPPS in your environment? Than you have a problem with the LittleCMDB. The Workflow will stop on the “Extract virtual machine information” workflow.

Why that?  To answer this Question we must take a look at the Workflow and the API. Let’s start with the Workflow. The Workflow exist out of different elements. The first element “Get Folder” grabs the Folder for the virtual machine.

For a “normal” virtual machine this works perfectly. The element uses the VM name and the “parent” object in the API to get the needed information.

Now let’s have a look on a virtual machine which is located under a vAPP.

Did you see the difference? For a virtual machine the parameter “parent” is used and the parameter “parentVApp” is Unset. For a virtual machine under a vApp that’s changed. So, when the Workflow hits a virtual machine located under a vApp the Workflow will fail.

How can we fix this problem? Don’t worry, that easy 😉

First, we have  to copy the Workflow “Extract virtual machine information”. We do so by going to:

Library –> vCenter –> Virtual Machine management –> Others There we can find our Workflow.

Just “right click”  on the Workflow and choose in the menu “Duplicate Workflow”.

Give the Workflow a name, I take the name “Extract virtual machine information_WithChanges” and choose a location for the Workflow. I would recommend  to keep all your customized workflows together. I will insert the Workflow into my folder and there in a subfolder “Helper” (for me that is better to export my project 😉 ). Copy the version history.

After we have duplicated the Workflow, we go to the chosen Folder and edit it.

First I change the Version history and insert a comment.

Then we go to the Schema Tab and there to the “Get Folder” Element. Here we change the Scripting to:

if (vm.parent != null){
folder = vm.parent;} else
folder = vm.parentVApp;}

folderName =;
folderId = folder.sdkId;

The scripting here is simple. We just look if the parent value is unset, then we use parentVApp. After we are finished validate and save the workflow.

At last, we go to our “GetVMConfig” Workflow. There we delte the “Extract virtual machine information” Workflow and insert our “Extract virtual machine information_WithChanges” workflow.

After that, insert the connections and the vm parameter (VMtoGet). Normally it should be insert automatically. Validate our Workflow and enjoy.

That’s all for Part7.

De Vcoportal Part7
De Vcoportal Part7
126.3 KiB

Adventures with the vCO AMQP Plugin

*** This is a Guest Article, written by Mathew Quinn – Thanks, Mat! ***

Having had some experience with a variety of plugins for vCO that range in quality, I was wondering what to expect from the AMQP plugin. I approached the plugin with a good deal of skepticism – which did turn out to be completely unfair!

Having had no prior experience with message queues, my first task was to learn about all things queue.

Selecting RabbitMQ to experiment with was the obvious choice. I believe VMware now own this product which can be used in a free edition or as part of the larger vFabric suite. The Plugin also comes with a little rabbit icon, so I’m guessing this is what they’re suggesting. The plugin can however work with any AMQP-based message broker.

Now there were some AMQP concepts to learn, which turned out to be very simple and well presented. I would recommend a read through the following documentation if you are new to AMQP or RabbitMQ:

Next I provisioned a CentOS 6 VM and installed RabbitMQ which was ridiculously easy. In order to get moving faster, I also installed the RabbitMQ management plugin that presents a convenient web interface where you can define exchanges, queues and bindings, and also publish and retrieve messages.

Get Started with AMQP in vCenter Orchestrator

Installation of the AMQP plugin for vCO was easy so I’ll skip that part. It installs the same as any other Plugin for vCO.

Upon installation, some new workflows are now present in the vCO Client

Right, very straightforward. There appeared everything I needed to get started.

A good place to start is running the ‘Add a Broker’ workflow which adds a broker (AMQP server) to the vCO inventory. This is the root object from the point of view of the plugin’s inventory. Once you have a broker in your inventory you’re free to begin receiving and publishing messages, which works quite nicely.

On the AMQP Broker I added a queue called ‘Inbox’ and a queue called ‘Outbox’, the intention being to both receive a message in vCO, and publish a message back.

And published a message to the inbox, ready to receive.

Now the moment of anticipation. Will this work first go? I run the ‘Receive a text message’ workflow in vCO client.

Presto! Success! My message has been received in the vCO client perfectly. I’m starting to like this.

Now let’s send a message back to the outbox.

The workflow runs successfully, and looking at the broker, there is indeed a message sitting in the queue to be fetched.

Nice! The reply was received successfully too. Already things are starting to look very nice indeed.
Now to step things up a notch. What I’m really interested in with the AMQP plugin are the event-driven possibilities. I want to be able to trigger a workflow from an inbox message, do some processing, and respond to the outbox.

Event-driven Message Handling

Rather than reinvent the wheel, I decided to check online for examples of just this operation and stumbled across some workflows published on the subject:
The example was focused around handling vCloud Director message notifications. I imported the package and took a look.

The author achieves this by utilising a policy connected to an AMQP subscription that triggers a scripting event. When a message arrives in the queue that is subscribed to, the event fires and the script runs. Neat.

The script that runs operates by firing up a workflow – but this is where things start to get messy.

Oh no – is that a hard coded workflow ID in the script? It sure is. If beings greater than myself have found that this is the best way to do things, we’re in trouble. I just can’t do things like this when coding and enterprise-grade solution.

Investigating policies a bit further, it turns out that it is possible to directly trigger a workflow from an event rather than run a script. I decide to give this a try.

Firstly I must create a subscription to my inbox queue, and workflow that I intend to run. Subscriptions are for the sole intent of receiving messages from a queue and they live in the vCO inventory. You can create one by running the ‘Subscribe to queues’ workflow.

I also create an empty workflow to trigger on receiving a message. Now I have all the components I need to build my policy.

This is all well and good, but I need some input to my workflow. I want the workflow to be able to inspect the message received. I create a new parameter to the workflow of type ‘Any’.

Now to hook this up to the policy. I will gloss over the details a bit here but, suffice to say, I found passing in the ‘self’ object of type AMQP:Subscription the most reliable way to get all the details of the message received and, additionally, the subscription that received the message, into the workflow using only one input. The other possible inputs, event key headers, properties, and body, achieve this only in part, and with varying degrees of success.

In the workflow itself, I add a scripting object to log the message, and nest a ‘Send text message’ workflow to reply to the outbox.

Now I am all ready for the big test. I should be able to send a message to the inbox queue, Orchestrator will log this, and send a reply to the outbox. With the policy started, I send a message to the inbox.

Fantastic, I can see the message body logged in the workflow run.

And the reply is present in the outbox queue!

In Summary, the vCO AMQP plugin offers an exciting range of possibilities. It interfaces simply and reliably with AMQP Brokers and could be used for a variety of purposes.