vRA 7 – Getting more information in workflows from the vRO ExecutionContext object

When a vRO workflow or action is called from vRA, additional input parameters (in addition to those specified as the workflow/action inputs) are provided in the Execution Context object. These can be very useful as they contain additional data that can be used inside the workflows. A couple of good examples would be the user that requested the resource or the name of the tenant.

Here is a list of parameters provided inside the Execution Context (those without a description I’m still trying to figure out):

 Parameter Name  Description
__asd_catalogRequestId
__asd_correlationId  The Request ID
__asd_requestInstanceId
__asd_requestInstanceTimestamp Request Date & Time
__asd_requestInstanceTypeId The lifecycle ID
__asd_requestTraceId
__asd_requestedBy The UPN of the user who made the request
__asd_requestedFor The UPN of the user the request was on behalf of
__asd_targetResourceId
__asd_targetResourceProviderId
__asd_targetResourceProviderTypeId com.vmware.csp.iaas.blueprint.service
__asd_targetResourceTypeId Type ID, i.e. ‘machine’
__asd_tenantRef The friendly name of the tenant (i.e. vsphere.local)

Wait, where is ‘__asd_subtenantRef’? More on that in my post here (soon).

You can also see these in the variables tab for the workflow run:

List all parameters

The parameters and their values in the execution context object can be retrieved using the System scripting class. There is a method called ‘getContext()‘, which returns an object called ‘ExecutionContext‘. The ExecutionContext object has the following methods:

boolean contains(String name)
Object getParameter(String name)
Array parameterNames(String name)

Insert the following code into a scripting task in your workflow to list all the parameters and their values:

Retrieve the value for a specific parameter

To retrieve a value for a specified parameter the following example can be used:

Retrieves the tenant name and sets it to a variable/attribute.

If anyone can shed some light on what the other parameters do then please comment and I’ll update the page.

Extend vRA UI Login Timeout

Nothing frustrates me more than returning to the vRA UI, clicking something and then have it immediately log me out. This appears to be quite random a lot of the time and whilst I can appreciate that this is in the interest of security, I find it a little too aggressive. This can be changed by extending the life of the authentication cookie using the following procedure.

Log in to the vRA appliance using SSH (SSH will need to be enabled via the vRA Appliance VAMI interface if it is not already). Edit the following file:

Add the following line to the end of the file:

Where ‘28800’ is the number of seconds (8 hours) until the authentication cookie expires. Set this based on your own requirements.

Save the file and then restart the vcac-server service

It will take the usual 5 minutes or so for the server to fully start up and once complete the new settings will be applied.

Repeat this process for any remaining appliances in the cluster.

vRealize Orchestrator cluster nodes not in sync with embedded vRA Appliance

I have come across this issue a number of times where the secondary vRO cluster node is not in sync with the primary node (one thing to note is that the synchronisation status is relative to the node you are logged on to).

The option to synchronise the nodes is not available because I am using vRO that comes embedded with the vRA appliance. The reason this option is not available is because vRA “should” be managing the state of the cluster nodes, which is does from a vRO client prospective but not when you make changes via the Control Center (such as changing the Admins group).

To workaround this issue and unlock the hidden options you will need to append “?advanced” to the end of the URL. For example, if you are on the Orchestrator Cluster Management page add ?advanced to the end of the URL, which should look like this:

https://vro_server:8283/vco-controlcenter/#/control-app/ha?advanced

When the page refreshes you will notice that a new button has appeared on the bottom.

Clicking on this button will reveal two new options:

  • Push Configuration
  • Push Configuration and restart nodes

Select “Push Configuration and restart nodes”, which will push the configuration and automatically restart the vRO service on the secondary node.

A message will be displayed if this is successful.

It will take approx 10 minutes for the secondary node to start up completely so grab a coffee at this point.

Refresh and both nodes should now show as “Synchronized”.

Remove ‘Default Machine Prefix’ for a Business Group

When I was building vRA 7 and figuring everything out, at some point I set the ‘Default machine prefix‘ for the Business Groups. When you first create a Business Group, setting the default machine prefix is optional; However, if you do set this value then there is no way to unset it, which I find extremely annoying. As I don’t currently use specific prefixes for business groups, I was feeling a little OCD having to set this to some other prefix value.

defaultprefix

I was able to ignore this for a while until I installed the Custom Hostnaming Extension for vRA7 by Dailyypervisor. This extension is really awesome and has helped me massively overcome my requirement to create dynamically generated hostnames. The hostnames are based on our internal naming convention and I make good use of Custom Properties for this. For testing, I simply created a very basic custom hostname scheme ‘{LOC}-GSTEST{##}’, with {LOC} being set on one of the vSphere endpoints.

hostnamescheme

At first this appeared to work just fine, until randomly some machines would be provisioned using a different hostname. The other hostname was based on another machine prefix that I had created previously and was configured as the default for the Business Group, which was ‘ES-VWOI-MANA##’. The image below shows the results of 7 machines provisioned using the custom hostname extension.

machines

Clearly what is happening here is that on each provisioning attempt, it is randomly selecting a different machine prefix. What is also interesting is that both prefixes get incremented. In fact, that’s another issue with having a default one set for the business group (or even within the Blueprint), is that they are ‘allocated’ and incremented even before the EBS is used (which is when the custom hostnaming extension kicks in, at the requested stage, which is still AFTER the allocation). I have had a small look at the code for the workflow and can see that it’s identifying that the custom hostname scheme already exists, but I haven’t yet looked into why it’s setting the wrong one.

I figured the easiest workaround for now would be to simply remove the default machine prefix from the business group and make sure no one accidently sets it. But this is when I realised you can’t do that by simply editing the group via the IaaS interface. To cut a long story short, you have to manually remove this on the database, both the SQL database used by IaaS and the PostGres database used by vRA.

Continue reading

Resolve vRA/vCAC VM to vCenter VM

If you want to perform configuration tasks against a VM during the deployment process or even for Day 2 operations then you will need to resolve the vRA managed VM to a vCenter VM of type VC:VirtualMachine in your vRO workflows. I initially required this when applying tags to a VM during the BuildingMachine LifeCycle POST state, which involved using the VAPI endpoint.

vRO with the vRA plugin installed will make available two modules with some pre-defined actions .

  • com.vmware.vcac.asd.mappings
  • com.vmware.vcac.asd

findvcvmbyuuid

The two actions that we are interested in are ‘mapToVCVM‘ and ‘findVcVmByUuid‘. Let’s take a look at these two actions.

mapToVCVM

Inputs: VMProperties(Properties)
Return type: VC:VirtualMachine

This action has an input ‘VMProperties‘ of type ‘Properties‘, which is passed to it by the calling workflow or action. If you don’t know what this is, it is the vRA payload sent to vRO by the Event Broker Service (EBS). I’ll post another article at a later date on how I am doing this if you’re not sure. The first line of the script extracts the custom property ‘VirtualMachine.Admin.UUID’, which returns the unique UUID of the virtual machine (in previous versions of this action, the MoRef was used which is not unique across multiple vCenter Servers) and stores the value in ‘vmUuid‘.

The second line returns the result of ‘System.getModule(“com.vmware.vcac.asd”).findVcVmByUuid(vmUuid)’ of type VC:VirtualMachine. This code calls another module/action and passes ‘vmUuid‘ as an input (refer to the previous image if you’re unsure what is happening here and it should make sense). The result of this is returned to the original calling workflow/action as a VC:VirtualMachine type, which will be the vCenter managed VM object.

findVcVmByUuid

Inputs: VmUuid(String)
Return type: VC:VirtualMachine

This action has an input ‘VmUuid‘ of type ‘String‘. As you saw from the ‘mapToVCVM‘ action, this string is passed over with the value of the UUID for the virtual machine. The action then discovers the configured vCenter endpoints and performs a search on each for the VM until a result is found and returns it.

At this point you have probably worked out that you don’t need to use ‘mapToVCVM‘ at all and we could simply extract the UUID ourselves and then make a call to the ‘findVcVmByUuid‘ action.

Continue reading