Scripting from vCAC Workflows (Southbound)

VCAC is really easy to setup and make 3rd party callouts at different states in the machine’s lifecycle. One of the most common requests we had to implement some very specific logic around VirtualMachine naming standards.

There are multiple ways to make 3rd party callouts natively from VCAC:

  • SSH
  • Powershell
  • RunProcess
  • VMware VCO – VirtualCenter Orchestrator (that orchestrates WAY more than just VirtualCenter!!) – this gives you a whole host of ways to interact with our datacenter. With more VMware partners adding additional plugins like ServiceNow, F5, and many more its certainly a great option.

Machine State Overview

Every machine whether a VMware VirtualMachine, MS HyperV, Amazon Public cloud machine or DELL/Cisco/HP Blade can have the same State management capability. 
The main Machine States that are usually used when applying custom logic are:
  • AwaitingApproval
  • BuildingMachine
  • MachineProvisioned
  • TurningOn/TurningOff
  • DeactivateMachine
Custom workflows can be added to run prior or post to the MachineState applying its business logic.

Example –  Custom Hostname Workflow

Process flow:
  1. User requests a machine
  2. Prior to the machine building a workflow will be called to execute a powershell script and update the machines’ hostname.
  3. The machine will then start to build with the correct name
How To:
Either create a new workflow using the Visual Studio Designer or use one of the Workflow Stubs that are shipped out of the box. The workflow stub that would be needed in this case is “WFStubBuildingMachine“. To enable this workflow to run add this custom property to the VirtualMachine blueprint you wish to assign this policy “ExternalWFStubs.BuildingMachine” 
Using the Visual Studio Addin – Create a new workflow to run in the BuildingMachine State

The Powershell script

# Update VirtualMachine.VirtualMachineName property with new name based on incoming custom properties
$location;
$serverType;

#$Machine object is the VirtualMachine and passed in by the calling workflow

#$Machine.VirtualMachineProperties is populated with all of the VirtualMachines properties and can be a useful way to store metadata, in this case Location & ServerType will be used to form  the new hostname

#$MgmtContext object is the connection to the VCAC Database over a RESTFul connection

foreach ( $p in $Machine.VirtualMachineProperties) {
if ($p.PropertyName.ToLower() -eq “location”) {
$location = $p.PropertyValue;
}
if ($p.PropertyName.ToLower() -eq “servertype”) {
$serverType = $p.PropertyValue;
}
}

# Save new machine name to DCAC Inventory
$machineName = $location + $serverType + $Machine.VirtualMachineName
$Machine.VirtualMachineName = $machineName.ToUpper();
if ( $MgmtContext -ne $null ) {
$MgmtContext.UpdateObject($Machine)
$MgmtContext.SaveChanges()
}
Load the script into the Repository
CloudUtil -n ChangeMachineName -f ChangeMachineName.ps1 -d “Change machine hostname”
The Workflow
Open the Workflow to the Custom Code FlowChart where you can add activities.
1) Load the VirtualMachine into the Workflow, use an Assign Activity and store in the variable machine
Linq Query:
machine = mgmtContext.VirtualMachines
    .Expand(Function(v) v.VirtualMachineProperties)
    .Where(Function(v) v.VirtualMachineID = VirtualMachineId)
     .FirstOrDefault()
This query is loading from the Database a VirtualMachine object based on the incoming VirtualMachineId (for context). It is also Expanding the VirtualMachineProperties associated with the machine, by default if we dont do this it will be an empty array. As we wish to retrieve custom properties (Location & ServerType) we must expand.
For information about  common Linq queries see this blog
2) Create a local workflow variable “scriptContent” of type String
3) Add the Activity from the CDK GetScriptFromName


assign the following properties to the GetScriptFromName activity:

ScriptName=”ChangeMachineName“
ScriptContent=”scriptContent“
4) Add the InvokePowerShell Activity with the following Properties:
CommandText=scriptContent
PowerShellVariables= we are going to add 2 variables in this collection:
The final workflow will look like this:
Install the workflow into the DCAC Repository and apply the External XML file into the VCAC Application Server.

Summary


Whats cool in my opinion here is the entire VirtualMachine object as well as the REST/DB connection is passed as objects you can use in the script. Any object can be serialised in, the Host or ManagementEndpoint are also quite common so you can connect to 3rd party endpoints and use centralised credentials