TAG: ComplexWorkflows

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:

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


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.

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

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:

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

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:


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.