Sydney VMUG - Getting started with vRA

Hi everyone!

If you’re reading this, you probably saw my Getting started with vRA presentation at the Sydney VMUG earlier tonight.  I hope you found something useful in the short 20-30 minute timeslot I had to work with.  Delivering some useful content without blowing the time constraint was my biggest challenge, because vRA can be a bit of a complex topic!  As promised, this post contains some information that was discussed tonight and which I hope will help you as you start on your vRA journey.

Hands-on Labs

VMware has provided several great hands-on labs which I would highly recommend if you’re trying to learn vRA.  They range from beginner to advanced, and cover all the important topics like single/multi-machine blueprinting, XaaS blueprints, and extensibility with vRO, as well as an extremely important topic which I didn’t cover: the structure of your AD groups > vRA business groups > entitlements > reservations > services > catalog items.

The key labs which cover these topics are:

• HOL-1721-USE-1 - vRealize Automation 7 Basics
• HOL-1721-USE-2 - vRealize Automation 7 Advanced
• HOL-1721-USE-3 - vRealize Automation Advanced Extensibility
• HOL-1790-CHG-1 - vRealize Automation: Challenge Lab

Referenced Documentation

The first document I referenced was the vRealize Automation 7.3 custom properties guide.  It can be tricky to find properties in there if you don’t already know what you’re looking for, but the workflow to log all properties in the payload (which is provided later in this post) can help.  The main properties you’ll use will probably be the ones starting with VirtualMachine.  Also note that some properties (like the __clonefrom property that I updated during the presentation) are not listed in the documentation with the preceeding underscores.

Another document which is very useful (but which I didn’t mention due to time constraints) is the vRealize Automation 7.3 Extensibility guide.  It contains all sorts of useful information about using the Event Broker to extend your workflows through vRO.

Keep in mind that virtual machine custom properties are not included in the payload, unless you add one or more custom properties to identify the lifecycle states you want to pass the virtual machine properties for.  The format for the custom property is Extensibility.Lifecycle.Properties.{workflowName}.{stateName}.  You can find all the states for the VMPSMasterWorkflow32 workflow on page 24 of the extensibility document, or online in the documentation centre.  An example of the completed format would be Extensibility.Lifecycle.Properties.VMPSMasterWorkflow32.Requested.

Using Vrm.DataCenter.Location

This custom property allows you to specify a compute resource as a target for provisioning.  When using vRA with vSphere, each cluster has a corresponding compute resource within vRA.  There are two main ways you could use this property: specify a location for each compute resource (maybe using a naming convention of Site-ClusterName), or create locations for each site and tag all compute resources within the site with the same location, using another method to select the specific cluster.

Here’s the steps needed to make this work:

1. Specify location name/value pairs in DataCenterLocations.xml file.  This file is located at C:\Program Files (x86)\VMware\vCAC\Server\Website\XmlData\DataCentreLocations.xml on your IaaS server, which in a Hands-on Lab is probably called iaas-01a.corp.local.
2. In vRA, associate a location with each compute resource.
3. Create a custom property with the name Vrm.DataCenter.Location.
   • Give it a friendly label
   • Set data type to string
   • Set required to yes
   • Set display as to dropdown
   • Create name/value pairs where the value matches those in DataCenterLocations.xml
4. Add the Vrm.DataCenter.Location custom property to a virtual machine on a blueprint and ensure it’s set to to show in request.
5. Deploy a new VM and choose the relevant location.
6. Profit.

Workflow scripts

To get these workflows to run, create them in vRO and then configure an event subscription to trigger the workflows at the required states.  Don’t forget the custom Extensibility.Lifecycle properties listed above!  Also, don’t forget to publish the subscription after you create it - that is extremely easy to forget.

Get all custom properties

Create a workflow with an input parameter of payload with a type of properties.  Add a scriptable task to the workflow and add the input parameter from the workflow to the scriptable task.  The visual binding should look like this:

On the scripting tab of the scriptable task, add the following script:

 1var executionContext = System.getContext();
 2
 3System.log("BlueprintName: " + payload.get("blueprintName")) ;
 4System.log("ComponentId: " + payload.get("componentId")) ;
 5System.log("ComponentTypeId: " + payload.get("componentTypeId")) ;
 6System.log("EndpointId: " + payload.get("endpointId")) ;
 7System.log("RequestId: " + payload.get("requestId")) ;
 8System.log("VirtualMachineEvent: " + payload.get("virtualMachineEvent")) ;
 9System.log("WorkflowNextState: " + payload.get("workflowNextState")) ;
10
11var lifecycleState = payload.get("lifecycleState") ;
12System.log("State: " + lifecycleState.get("state")) ;
13System.log("Phase: " + lifecycleState.get("phase")) ;
14System.log("Event: " + lifecycleState.get("event")) ;
15
16var machine = payload.get("machine") ;
17System.log("ID: " + machine.get("id")) ;
18System.log("Name: " + machine.get("name")) ;
19System.log("ExternalReference: " + machine.get("externalReference")) ;
20System.log("Owner: " + machine.get("owner")) ;
21System.log("Type: " + machine.get("type")) ;
22System.log("Properties: " + machine.get("properties")) ;
23
24var vRAVmProperties = machine.get("properties") ;
25if (vRAVmProperties != null) {
26    var log = "";
27    log += "vRA VM Properties :\n";
28    var array = new Array ();
29    for each (var key in vRAVmProperties.keys) {
30        array.push(key + " : " + vRAVmProperties.get(key));
31    }
32    array.sort();
33
34    for each (var line in array) {
35        log += " \t" + line + "\n";
36    }
37    System.log(log);
38}

This workflow can trigger at whatever states and/or phases that you’re interested in seeing.

Workflow to update virtual machine template

This is the workflow I ran through during the presentation to update the __clonefrom property (which contains the vSphere template used for cloning) in the request payload with the value of my location- or cluster-specific templates.  The benefit of doing this is so we can ensure our blueprints deploy from site-local storage (especially important when you have geographically dispersed data centres) without having to duplicate blueprints and hardcode the site-local template in each one.

This workflow combines the Vrm.DataCenter.Location default property with the VMUG.BuildTemplate custom property to create a string which corresponds to the names of the templates in the vSphere environment.   These two custom properties should be added to the machine on the blueprint.

I chose to pass the partial template name through the VMUG.BuildTemplate property instead of using the one already configured on the blueprint itself so I don’t have to worry about script logic to remove the existing location suffix and append a new one.  Another reason I like this approach is so the workflow can be easily reused for other operating system types.  If I wanted to set up a Windows Server 2016 blueprint, I can set the value of VMUG.BuildTemplate to equal WindowsServer2016.  However, as this is essentially all just down to JavaScript, there are a multitude of ways you can make this work depending on your requirements.

Note that it’s good practice to add a custom prefix to the start of your organisation’s custom property names, to prevent conflicts with any default out-of-the-box custom properties (hence why my property is called VMUG.BuildTemplate).

To set this up, create a workflow with an input parameter of payload with a type of properties.  Add an output parameter of virtualMachineAddOrUpdateProperties with a type of properties.  Add a scriptable task to the workflow and add the input and output parameters from the workflow to the scriptable task.  The visual binding should look like this:

On the scripting tab of the scriptable task, add the following script:

 1var vRAVmProperties = payload.get("machine").get("properties") ;
 2var Site = vRAVmProperties.get("Vrm.DataCenter.Location") ;
 3var BuildTemplate = vRAVmProperties.get("VMUG.BuildTemplate") ;
 4var NewTemplate ;
 5
 6NewTemplate = BuildTemplate + "-" + Site ;
 7
 8System.log("Site: " + Site) ;
 9System.log("Build template: " + BuildTemplate) ;
10System.log("New build template: " + NewTemplate) ;
11
12virtualMachineAddOrUpdateProperties = new Properties () ;
13virtualMachineAddOrUpdateProperties.put("__clonefrom", NewTemplate) ;

This workflow should trigger at the VMPSMasterWorkflow32.BuildingMachine state, during the Pre phase.  Here’s a screenshot of the conditions I configured on my event subscription for this workflow.

You can use the previous_get all custom properties_ workflow triggered by the event broker at the BuildingMachine state to see that the __clonefrom property has been updated.

Conclusion

Well, I think that’s it.  If you have any additional questions or comments, please leave a comment below and I’ll do my best to help out.  Thanks!