Adding VM Notes and Custom Attributes with vRA8

In past posts, I started by creating a basic deployment infrastructure in Cloud Assembly and using tags to group those resources. I then wrote an integration to let vRA8 use phpIPAM for static address assignments. I implemented a vRO workflow for generating unique VM names which fit an organization's established naming standard, and then extended the workflow to avoid any naming conflicts in Active Directory and DNS. And, finally, I created an intelligent provisioning request form in Service Broker to make it easy for users to get the servers they need. That's got the core functionality pretty well sorted, so moving forward I'll be detailing additions that enable new capabilities and enhance the experience.

In this post, I'll describe how to get certain details from the Service Broker request form and into the VM's properties in vCenter. The obvious application of this is adding descriptive notes so I can remember what purpose a VM serves, but I will also be using Custom Attributes to store the server's Point of Contact information and a record of which ticketing system request resulted in the server's creation.

New inputs

I'll start this by adding a few new inputs to the cloud template in Cloud Assembly.

New inputs in Cloud Assembly

I'm using a basic regex on the poc_email field to make sure that the user's input is probably a valid email address in the format [some string]@[some string].[some string].

 1inputs:
 2[...]
 3  description:
 4    type: string
 5    title: Description
 6    description: Server function/purpose
 7    default: Testing and evaluation
 8  poc_name:
 9    type: string
10    title: Point of Contact Name
11    default: Jack Shephard
12  poc_email:
13    type: string
14    title: Point of Contact Email
15    default: jack.shephard@virtuallypotato.com
16    pattern: '^[^\s@]+@[^\s@]+\.[^\s@]+$'
17  ticket:
18    type: string
19    title: Ticket/Request Number
20    default: 4815162342
21[...]

I'll also need to add these to the resources section of the template so that they will get passed along with the deployment properties.

New resource properties

I'm actually going to combine the poc_name and poc_email fields into a single poc string.

1resources:
2  Cloud_vSphere_Machine_1:
3    type: Cloud.vSphere.Machine
4    properties:
5      <...>
6      poc: '${input.poc_name + " (" + input.poc_email + ")"}'
7      ticket: '${input.ticket}'
8      description: '${input.description}'
9      <...>

I'll save this as a new version so that the changes will be available in the Service Broker front-end.

New template version

Service Broker custom form

I can then go to Service Broker and drag the new fields onto the Custom Form canvas. (If the new fields don't show up, hit up the Content Sources section of Service Broker, select the content source, and click the "Save and Import" button to sync the changes.) While I'm at it, I set the Description field to display as a text area (encouraging more detailed input), and I also set all the fields on the form to be required.

Service Broker form

vRO workflow

Okay, so I've got the information I want to pass on to vCenter. Now I need to whip up a new workflow in vRO that will actually do that (after telling vRO how to connect to the vCenter, of course). I'll want to call this after the VM has been provisioned, so I'll cleverly call the workflow "VM Post-Provisioning".

Naming the new workflow

The workflow will have a single input from vRA, inputProperties of type Properties.

Workflow input

The first thing this workflow needs to do is parse inputProperties (Properties) to get the name of the VM, and it will then use that information to query vCenter and grab the corresponding VM object. So I'll add a scriptable task item to the workflow canvas and call it Get VM Object. It will take inputProperties (Properties) as its sole input, and output a new variable called vm of type VC:VirtualMachine.

Get VM Object action

The script for this task is fairly straightforward:

1// JavaScript: Get VM Object
2//    Inputs: inputProperties (Properties)
3//    Outputs: vm (VC:VirtualMachine)
4
5var name = inputProperties.resourceNames[0]
6
7var vms = VcPlugin.getAllVirtualMachines(null, name)
8System.log("Found VM object: " + vms[0])
9vm = vms[0]

I'll add another scriptable task item to the workflow to actually apply the notes to the VM - I'll call it Set Notes, and it will take both vm (VC:VirtualMachine) and inputProperties (Properties) as its inputs.

Set Notes action

The first part of the script creates a new VM config spec, inserts the description into the spec, and then reconfigures the selected VM with the new spec.

The second part uses a built-in action to set the Point of Contact and Ticket custom attributes accordingly.

 1// Javascript: Set Notes
 2//    Inputs: vm (VC:VirtualMachine), inputProperties (Properties)
 3//    Outputs: None
 4
 5var notes = inputProperties.customProperties.description
 6var poc = inputProperties.customProperties.poc
 7var ticket = inputProperties.customProperties.ticket
 8
 9var spec = new VcVirtualMachineConfigSpec()
10spec.annotation = notes
11vm.reconfigVM_Task(spec)
12
13System.getModule("com.vmware.library.vc.customattribute").setOrCreateCustomField(vm,"Point of Contact", poc)
14System.getModule("com.vmware.library.vc.customattribute").setOrCreateCustomField(vm,"Ticket", ticket)

Extensibility subscription

Now I need to return to Cloud Assembly and create a new extensibility subscription that will call this new workflow at the appropriate time. I'll call it "VM Post-Provisioning" and attach it to the "Compute Post Provision" topic.

Creating the new subscription

And then I'll link it to my new workflow:

Selecting the workflow

Testing

And then back to Service Broker to request a VM and see if it works:

Test request

It worked!

New VM with notes

In the future, I'll be exploring more features that I can add on to this "VM Post-Provisioning" workflow like creating static DNS records as needed.

More vRA8