Set Edge Default Route / Default Gateway using vRealize Orchestrator


As part of some workflow I am building for a customer, I need to automate assigning the default route (default gateway) for an vCNS Edge appliance, using vRealize Orchestrator.


The provided NSXDefaultRoute, which can be used with NSXEdgeManager.setDefaultRoute() per the documentation, has read-only properties and the NSX Orchestrator Plugin 1.0.4 provides no further documentation to my knowledge on how to use this scripting object:


There are two accessors available as part of the NSXDefaultRoute scripting object.  To my knowledge, these are not documented.

  • NSXDefaultRoute.setvNicIndex(string vnicindex)
  • NSXDefaultRoute.setGatewayIpAddress(string ip)

Note, there is no accessor for MTU, although as shown below that is an option in the default gateway config.

This example code works with vRealize Automation 7.1 and the embedded Orchestrator service.

Setup a new workflow with these variables as input, and the below code in a scripting task, and it should work for you too.

Input Parameters

  • Variable nsx is a NSX:Connection object specifying my vCNS Manager in vRO inventory
  • Variable edgeId is a string object specifying the edge objectId, such as edge-28

Here’s the results after running this code

FitBit HR Data Raw

Excited by the Fitbit Charge 2’s second by second heart rate data, but frustrated by the lack of an easy export function for accessing this data in raw form, I rolled a very quick Node.js app to give me CSV-formatted raw data from Fitbit.  Note that to access the APIs I am using, you either need special approval, or a Personal application registered on the Fitbit developer portal.

It looks like this, after the app is initially authorized:

Clicking the “Get HR for Today” link gives me this raw CSV:

And so on.

Here’s the bare bones code, posted as a gist on GitHub:

vRealize Automation 7.0 to 7.1 Upgrade the SQL Database Manually



Following the installation instructions for manual SQL database upgrade using vRealize Automation 7.0 to 7.1, the vRA VAMI installation download page didn’t have a link for, only  I manually created the path https://<vra>:5480/installers/ and continued with the upgrade.

Problem Details

Doing a manual update of the vRealize Automation IaaS MS SQL database, the vRealize 7.0 to 7.1 upgrade guide has this instruction:

I thought I followed the directions, but had errors and was missing the key utility DBUpgrade.exe in the ZIP file.  I eventually logged on the vRA server, found the file in /opt/vmware/share/htdocs/service/iaas/ to confirm it was there.  Only then did I realize I had been downloading the wrong file.  Apparently I do not have a link to download the database upgrade scripts on the installation interface.


Clearly, the file exists:

So I used the URL https://<vRA-appliance>:5480/installer/ and followed the install instructions from there.

vRealize Orchestrator additionalPropertyFilters Explanation


The Orchestrator VcPlugin getAll…() methods (such as VcPlugin.getAllDatastores(), VcPlugin.getAllVirtualMachines(), etc.) accept two parameters, additionalPropertyFilters and xpath.  Use of xpath has been well documented, but I had trouble finding information on additionalPropertyFilters.  Then, I found this explanation in the vRO Coding Design Guide, page 26:

For performance reasons, the returned objects are not fully populated with all of the properties but a pre-defined set of properties. The initial set can be determined by looking at the plugin inventory – all properties displayed in the inventory are in the initial properties set. If additional properties are needed, specify them during the getAll…(…) call so that the request from the vCenters can get a combined set of properties upfront. If this is not done and extra properties are referenced by the workflow or action then a remote call is made each time to vCenter to create a vCenter filter for the tuple <vm, property=”” name=””>, which wastes resources both for remote execution and for filter management on vCenter side.

Ah hah!


How To Use additionalPropertyFilters

A quick look at tells me the syntax is getAll…(string[], string).  As a test, I created a string array containing the name of all properties for the VcVirtualMachine class and ran this code successfully:



Performance Gains?

After performance testing, I found an average gain of 190ms per VM when reading all the VcVirtualMachine’s base level attributes.  However, I’m using for performance testing and it is less granular than I would like, also this wasn’t exactly the most controlled test – other environmental factors may have impacted performance, so your results may not be the same.

For the performance test, I ran 30 iterations of VcPlugin.getAllVirtualMachines() and averaged execution time with and without the additionalPropertyFilters parameter, 195ms and 165ms respectively.

Then I read all base-level properties from the first 200 virtual machines, using the object returned by each of the two types of calls, and averaged that time per VM.  I felt that this should trigger the “remote call… to vCenter” referenced above.


  • Per-VM property read time without additionalPropertyFilters: About 240ms
  • Per-VM property read time with additionalPropertyFilters: About 50ms


Hope this helps.



Cross-vCenter VM Clone using vRealize Orchestrator

vRealize Orchestrator includes a built-in workflow to clone VMs, but does not handle cross-vCenter VM cloning automatically.  This code is an early example of the necessary parameters to perform cross-vCenter VM clone using Orchestrator.  I hope it can serve as a starting point for others.

There are some parts of this code that need work, namely:

  • Workflow relies on input values for username and password to authenticate the destination vCenter.  I would prefer to use token based authentication from the VcPlugin’s connection to vCenter.
  • vCenter SSL Thumbprint is provided manually via input value.  I would prefer to find the SSL thumbprint from the VcPlugin’s existing trusted relationship with the destination vCenter.
  • VcPlugin.allSdkConnections[1] is not the right way to get the destination vCenter sdk connection.  This is the easiest one to fix.