Navigation
TAG: Workflows

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?)
vCO CLI 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.

Autocomplete

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:

[code]vm.destroy_Task()[/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)

Building vCAC Multi Machine Workflows

An important part of provisioning machines with vCAC is creating multi machine blueprints. As such, It is important to understand the flow of these kinds of blueprints when inside a custom workflow. With a regular workflow, things are pretty easy. The “virtualmachineid” parameter is passed into the workflow you are running at the moment (e.g workflow stubs, or any other custom workflows) and vualla everything is accessible with it, and the standard vCAC Designer actions will probably meet your needs.

When we’re running a workflow on a multi machine blueprint, things are a bit different, and some questions arise. Where does the workflow run? when? and how many times? how can I know which machines are inside the multi machine blueprint so I can interact with each separately during my workflow? Well, lets dive in and start answering some of these questions.

First of all lets get some must knowledge on MultiMachine blueprints / vCAC workflows:
– When you apply a custom property to a Multi Machine blueprint, it applies to all component virtual machines as well (Remember that when you apply a custom property or a stub that launches a workflow… yes, the workflow will run the number of N component VMs you have + 1 for the multi machine blueprint object)
– The mgmtContext parameter is in fact a link to the database  at the moment of the workflow. Use LINQ queries to interact with it and manipulate it.

So after this quick preview of things lets get to it.

The first thing you will want to do when running a multi machine workflow, is decide whither you want to run it from a master machine perspective, or for each machine separately. For this decision process we will use a simple “if” flow object. In order to determine what is exactly the machine type. We will start by getting the virtual machine object from the databaase, using a common LINQ query used in vCAC workflows:

[code]
/*This is a long line, please notice*/
mgmtContext.VirtualMachines.Expand(Function(v) v.VirtualMachineProperties).Where(Function(v) v.VirtualMachineID = VirtualMachineId).FirstOrDefault()

[/code]

This query will get us the current VM according to its ‘virtualmachineid’ which we get as a parameter into the workflow. The ‘MasterMachine’ variable is defined of type “DynamicOps.ManagementModel.VirtualMachine”  which is the object type definition for a VM in vCAC. Applying this LINQ query to the ‘MasterMachine’ variable is done with a simple ‘Assign’ workflow action:

Getting vCAC Machine Object

Now, with our Machine variable populated, we can check the following ‘If’ statement:

If Machine is Not a Component

This will essentially tell us whether the VirtualMachineId we’re working on is an actual VM in the MultiMachine BluePrint, or the “Master Machine” itself. meaning, the MultiMachine Blueprint Object itself.

Once we have the MultiMachine object, we can access all of it’s component VMs in a few more steps!

First, we will use a second LINQ query, to get a list of all Component Machines for our MultiMachine Blueprint.

[code]
mgmtContext.AppServiceComponents.Expand(Function(AppServiceComponents) AppServiceComponents.VirtualMachine.VirtualMachineProperties).Where(Function(v) v.AppServiceVirtualMachine.VirtualMachineID=VirtualMachineId).toList()
[/code]

We will create an ‘Assign’ workflow object to Assign this LINQ query to a variable we’ll create, with the name AllChildMachines, of type ‘System.Collections.GenericList’ This is a .Net type for a linked list. Each of the list’s component type should be ‘Dynamicops.ManagementModel.AppServiceComponent’

Gell All child Machines

AllChildMachines Variable Type

Next, we will need to create a ‘Foreach’ workflow object, that is also of type: ‘Dynamicops.ManagementModel.AppServiceComponent’. The Foreach loop will run on each of are associated vCAC VMs with the Master VM, and in at that part of the workflow, we will populate a VirtualMachine variable for that particular VM.

Foreach VM in Master Blueprint

The  LINQ Query used here, is similar to our first query, and is:

[code]
mgmtContext.VirtualMachines.Expand(Function(v) v.VirtualMachineProperties).Where(Function(v) v.VirtualMachineID = item.virtualmachine.virtualmachineid).FirstOrDefault()
[/code]

If your sharp, you’ll notice the logic change here, this time the LINQ Query is grabbing the virtual machine with the same ID as our current ‘item’ in the foreach loop, thus running on each and each VM.

If you’re using the regular vCAC Designer objects, such as “GetVirtualMachineName” you’ll use them like:

GetChildMachineName

From this point of the workflow you can run whatever you want on each ‘childmachine’. For example, apply a certain logic to look at all VMs , read properties, and decide what to do. Act upon each machine separately, or whatever else you might need to do. I recommend using the ‘Flowchart’ object for maximum flexibility (and not the sequence object shown here for easier reading purposes).

Don’t forget to set our last variable, “ChildMachine” of type ‘DynamicOps.ManagementModel.VirtualMachine’!

Enjoy, and leave your comments below!

There are no more results.