TAG: Automation

vCO CLI Fling User Guide

The vCO CLI fling, is actually a quite powerful tool for those of you who want to explore vCO javascript programming. I noticed that there aren’t any extensive articles about it, so I figured I write one myself.

First, you will need to download the vCO Cli Fling here and download the vmoapp plugin. After that, we’ll need to download the vCO Cli itself from the drop down box (tar or zip, depends on your OS).
Once that is done, you’ll need to install the vmoapp plugin on vCO  through the plugin install section in vCO Configuration page. After we’ve successfully installed the plugin, (make sure you don’t see ‘ will be installed on next startup’ this means you are not done!) we’ll open up vCO client, a new vCO Cli folder with a ‘Start Session’ Workflow will appear!

vco cli workflow


What this workflow will do is run a 4 hour workflow (give or take), that the vCO Cli UI can hook into, and actually connect to the running workflows session. This enables us , with some wit, is to freely explore vCO Javascript objects, like you would normally do with Visual Studio, and also the ability to run code quickly, with instant result feedback, rather editing a test workflow, running it, loggin g results… running it again , etc.

Initial Configuration

To achieve this, what I usually do is to edit copy the “start session” workflow, into a specific plugin’s folder, and name it “Start a<plugin name> plugin session”.

For the sake of a simple example, I’ll use a simple VC:VirtualMachine object for this demonstration. But, when developing with new plugins its great to be able to execute an object’s method, and explore the result instantly. After copying the workflow to the folder with the proper name, we’ll edit the workflow, adding some predefined attributes of our choice to explore.

Here I’ll add a VC:VirtualMachine object for us to work on.

Adding Attributes


I’ll link the object we chose to explore into the SECOND scriptable task in the “Start a vCenter Plugin Session” workflow.
Add param to script

Connecting to our session

After everything is set, we’ll start the vCO CLI Session workflow.
Two optional input parameters available for us, ‘name’ and ‘ipaddress’. While I’m not quite sure what’s the purpose of ipaddress, giving the session a helpful name will allow me to identify the specific session with vCO CLI with ease.
The workflow will now be in a running state for about 3-4 hours from my experience. Next, we’ll start our vCO CLI session by opening the zip / tar folder on our client machine, and running vcocli-gui.bat
Make sure you have the java binary folder in your ‘path’ environement variable set on your computer . If you don’t have it set, just run this command in cmd.exe:

[code]setx PATH “%PATH%;C:\progra~1\Java\jre7\bin\” [/code]

Once you activated vCO CLI gui, you will get the login screen:
Screen Shot 2014-04-25 at 9.30.51 PM


After entering an IP address, and a proper username / password for our vCO server, we’ll get a list of active sessions, and choose which one we want to connect to. Be sure to click Attach, since we’re connecting to an existing session (with a specific object in it). We could also create a new general session.

Next we will see the actual vCO CLI (or rather, Dev UI?)

Exploring & Coding

Lets start exploring some of the features available to us with this interface. First, I’ll mess around with the VC:VirtualMachine I’ve passed in. The VM ‘EmptyPlayVM’.
By simply typing the variable name (vm) and since this interface hooks to an active vCO session, we can now explore it in a visual studio autocomplete style press ctrl+space, and ENTER to complete.


What’s nice about this, is that we can explore the object freely without the need to ask the system for output using System.print , just by clicking the ‘play’ button , which will execute our code.

Exploring Object

keep in mind that if you execute any methods on the object – they will happen for real! Say I wanted to execute this line of code:


My vCenter VM won’t be happy about it.
But non the less, this interface is just great for exploring API relationships, such as how to get to one object from another, what certain methods return and such.

Even more things to explore!

If you take a closer look at the help section of vCO CLI , you will notice that there are a lot more things that we’re able to do with this tool like:

  • Exploring the real time objects in the right side pane
  • Running actual vCO workflows with a simple command $workflows.Library.<path to workflow>
  • saving script files, and write functions.
  • parse existing script files, JSON files and more!

To sum it all up, this is a MUST tool, for anyone new to vCO javascript, and orchestration! It’ll help you take you vCO abilities to the next level, and become a vCO Jedi Master (as Burke , Christophe and Jeorg would say)

Dynamically Assigning Property Dictionary Values

What makes vCAC such a dynamic product is definitely the use of the Property Dictionary.
If you’re still not familiar with it, you can read about it here (or here)
When using the property dictionary, you can unleash the full potential of the product. When you are able to update the property dictionary values dynamically, the possibilities are endless.

One example of using this scenario of dynamically updated property dictionary is allowing the user to set which vSphere portgroup (or VLAN) the machine will have when created. When a new portgroup is created in vsphere, the vCAC machine request page will be updated automatically as well.

For this special (and really important) use case , I’ve written a powershell module for vCAC Property dictionary (currently is @ version v0.9) with the help of some REST/JSON Functions written by Tom O’rourke . You can download the powershell module at the bottom of the page as well. Now, with the help of powerCLI & and the vCACPSModule we can grab all of vSphere’s portgroups, and dynamically add them to a vCAC property. Lets see how!

First, we need to open a powershell console on our vCAC Module Manager web server , and type in the following commands:

– This will create a new Property Dictionary for us to use, we can do this through the UI as well.

Import-Module vCACPSModule
New-vCACProperty -server -PropertyName "VirtualMachine.Netowrk.Choice" -PropertyType DropdownList -IsRequired True

– Our second stage is to create and schedule a script with the following code, in order to get vsphere portgroups and dynamically insert them into the vCAC Property dictionary with the help of the vCAC Powershell Module (Adjust the logic for getting the networks you actually need by cluster / name etc / use different network choices for different blueprints etc)

# GrabvSphereNetworks.ps1
Import-Module vCACPSModule
Add-PSSnapIn vmware.vimautomation.core
connect-viserver $vCenter -username $user -password $Password
# Edit to retrieve portgroups according to any logic you want
$Networks = Get-virtualportgroup | where-object Name -match "dvp" | Select Name -unique
# Changes the network list to something in format of a comma delimited string: "net1,net2,net3"
$Networks = ($networks | select -expand name ) -join ","
# Updates the vCAC property with the new values
update-vcacpropertyattribute -server -PropertyName "VirtualMachine.Network.Choice" -AttributeName Networks -AttributeType ValueList -AttributeValue $Networks
disconnect-viserver -confirm:$false

– Third stage, is to add the “VirtualMachine.Network.Choice” property we’ve created to our blue print, and create a workflow for the machine to set “VirtualMahchine.Network0.Name” property, with the network we want it to have. Here, we’ll use the building machine stub workflow in order to do so.

Setting our blueprint with the relevant properties:

Adding the Blueprint with Custom Property we created

When requesting the machine we will be able to select a Network from our property:

Now lets create the workflow for actually setting the machine’s network property.

Open the vCAC Designer, and create a workflow for changing the VM network. First, load the “ExternalWFStubBuildingMachine” workflow, and edit it like so:


Don’t forget to create a Variable named “NetworkName” (or any other name) with a String Type.

Also, you need to set the red marked properties for each activity. On GetMachineProperty we’ll set

  • MachineID -> virtualmachineid
  • PropertyName – > “VirtualMachine.Network.Choice” (dont forget ” sign)
  • PropertyValue -> NetworkName (Our created string variable)

At the SetMachineProperty, we’ll just set

  • MachineID -> virtualmachineid
  • PropertyName -> “VirtualMachine.Network0.Name”
  • PropertyValue -> NetworkName (Our created string variable)

Now we’ll Load the workflow back to the database.

In order for this to work , technically the networks that are in the custom property should be checked at the vCAC reservation level. you can simply check all of the networks when you create the reservation, and re-select each newly added portgroup to the vSphere environment, while I figure out how to get this automatically done via the API’s as well :)

Also, you need to schedule the GrabvSphereNetwork.ps1 script , for it to update the dictionary property on a permanent basis.

But more importantly, this PS Module can be of use to plenty of other use cases, for example:

  • Building machines in specific vSphere Directories per property choice
  • Choosing Machine’s Service classification from CMDB (simply sync the dictionary properties with services existing in CMDB using powershell)

If you think of any other scenarios – Let me Know!!! Comment section is below :)

vCAC PS Module Download

You can see example usage of the module’s functions at the file’s bottom section! There are some really cool CSV capabilities!

There are no more results.