PowerNSX and vRA

Share on:


The following article is a guest post by Shane White. Shane is part of the VMware Professional Services team, based in Melbourne. Shane’s past, present and planned future external projects cover most of the VMware product suite: vSphere, vRealize (vROPS, vRLI, vRA, vRO & vRB) and NSX.

However, Shane has been working with VMware products since ESX 3.0.2 (released in 2007), having worked in IT/telecommunications for approaching 30 years. Shane achieved his VCDX-DCV in 2012 (being allocated no. #95). Shane is also working towards both VCDX-NV and VCDX-CMA. Shane’s motivation for the ‘internal’ project outlined in this post was to learn new skills and hone existing ones (In IT, if you don’t keep learning, you get left behind).


Since working at VMware, I’ve had the opportunity to delve much deeper into automation and orchestration.

Central to VMware’s portfolio of automation products are vRealize Orchestrator (vRO) and vRealize Automation (vRA). At VMworld this year (2017) in Las Vegas, I was able to obtain a hard-copy of the book Automating NSX for vSphere with PowerNSX. A bit later, I was chatting with a colleague about orchestrating an NSX deployment using PowerNSX, and he mentioned a script he’d written to orchestrate the deployment of isolated ‘test’ networks in NSX (see https://tonysangha.com/2017/08/03/human-logic-robot-automation/).

The script uses the PowerNSX module for Powershell. Liking a challenge, I began to wonder how we could drive the deployment (and removal) of isolated networks in NSX by leveraging vRO and vRA.

The end result of this task was a vRA blueprint with a provisioning form that looks something like this:

By providing the required info, the blueprint will deploy a combination of NSX Distributed Logical Routers, Edge Services Gateways and Logical networks, resulting in a deployment similar to that shown below.

The purpose of this article is to give an idea how we got there.

Powershell Script

All the deployments required for a test (bubble) network is done by means of a Powershell script.

The Powershell script provided in the link above was modified to provide the following functions:

  1. Instead of various elements’ names being set in code, they are passed to the script via parameters
  2. The number of isolated networks is variable (the script will work out how many test networks are required
  3. In a multi-site NSX environment, the site to deploy to, is also a script parameter, which is then used to set the appropriate NSX Manager connection

The script accepts a number of parameters. If running the script from a command prompt, the command structure would look something like the following:

1Bubble_network.ps1 [Site], [Bubble network name], [ESG Uplink IP/mask], [Bubble network 1 name], [Network 1 gateway/mask] {optional: , [Bubble network 2 name]...


In this example the script will deploy one test network (called Net-01, with a default gateway of in a Bubble environment called Test-01 into the vSphere environment called NSX-1.

The next example will deploy two test networks (called Net-01, with a default gateway of _10.10.10.1/2_4 and Net-02 with a GW of in a Bubble environment called Bubble-01 into the vSphere environment called NSX-2.

The script adds the bubble network name (in the examples above, ‘Test-01’ or ‘Bubble-01’) to the names of the DLR’s, ESG’s, Logical networks, security groups and firewall rules created. This helps identify them.

At the end, the script creates a log file containing details that would be required in order to automate the removal of the bubble network.

The modified script itself can be found as a Gist available at: https://gist.github.com/tonysangha/d151c400c4a6f72f045e6986414c05c3

vRealize Orchestrator

The workflow in Orchestrator is very simple, comprising of only 2 elements:

  1. Get Parameters, which is mainly a javascript used to arrange the Powershell parameters
  2. Invoke an External PowerShell script, which calls the actual Powershell script itself

Get Parameters

This element gathers the parameters and arranges them for passing to the Powershell script itself.

A number of Input Parameters were created, corresponding to the parameters accepted by the Powershell script.

The scripting tab shows what specifically this workflow element does.

Comparing the parameter order with the sample powershell command line earlier in this article, you’ll see they are the same. There is only one output attribute (scriptarg). This is fed to the next workflow element.

The Host parameter can be set only after another pre-defined workflow is run.

This workflow is called Add a PowerShell host and can be found under administrator -> Library -> PowerShell -> Configuration

1a PowerShell HostName{The name assigned to the Powershell host in the vRO console}
Host/IPFQDN or IP of the server to run Powershell commands
1b Host TypeRemote Host TypeWinRM
Transport ProtocolHTTP
1c User CredentialsSession ModeShared Session
User name{account with admin privileges on the PowerShell host. Use the format username@domain.local}
PasswordSelf explanatory
1d Advanced OptionsShell Code Page

In order to get Kerberos authentication to work, I needed to do a couple of things before registering the Powershell host:

  1. Configure the krb5.conf file on the vRealize Orchestrator server (see https://pubs.vmware.com/horizon-7-view/index.jsp?topic=%2Fcom.vmware.using.horizon-vro-plugin.doc%2FGUID-78806E5A-C562-4758-ABF4-CA46F07D9942.html)
  2. Configure WinRM on the Powershell host to allow connection using HTTP (see https://pubs.vmware.com/orchestrator-plugins/index.jsp?topic=%2Fcom.vmware.using.powershell.plugin.doc_10%2FGUID-D4ACA4EF-D018-448A-866A-DECDDA5CC3C1.html)

Given this was done in a lab environment, unencrypted data transmission was fine.

If you require encrypted transmission, see this link (https://pubs.vmware.com/orchestrator-plugins/index.jsp?topic=%2Fcom.vmware.using.powershell.plugin.doc_10%2FGUID-2F7DA33F-E427-4B22-8946-03793C05A097.html) and then set the ‘Transport Protocol’ in the table above to HTTPS (I haven’t actually tried this).

Once all this is done, run the ‘Add a PowerShell Host’ workflow. If all is well, you will be greeted with a tick.

Setting the Host and External Script parameters is done on the ‘General’ tab of the workflow itself.

To set the Host, click on Not Set

Expand PowerShell and select the Host you registered earlier (identified by the name you gave it), and then click select

For the ‘External Script’ parameter, type in the full directory path to the script itself.


‘Presentation’ controls what the requesting form looks like, and can also be used to change how the parameters are altered.

By default, all parameters are changed by entering the actual values into boxes (see a screenshot of an earlier version below)

This required all parameters to be manually entered, and when it came to the required isolated networks, they needed to be entered in the same format as if you were running the Powershell script manually. IE:

1Bubble network 1 name, Network 1 gateway/mask, [Bubble network 2 name], etc

I wanted to see how else it could be done.

The current version of the vRO form looks like this:

The differences are:

  • The order of parameters has been changed
  • The ‘Network Gateway’ now just requires a valid IP address (no /24, for eg added to the end)
  • The Network subnet mask is a drop-down menu

I’ve just added 2 options, but others could be easily be added:

  • An additional parameter (‘No. of networks’) has been added
  • The effect of this parameter is to show (or hide) additional network parameters.
  • The screenshot above shows the console with the No of Networks set to 1.
  • The screenshot below shows the same console with 2 networks selected

Note the additional network parameters.

While I only have set it for 1 or 2 networks, expanding the options is simply a matter of adding additional parameters and modifying the ‘Get Parameters’ script to add the extra network information.

How did I do this?

  • The Presentation tab of the vRO workflow is where the appearance (and, sometimes, operation) of the parameters can be controlled.
  • This is done by manipulating properties associated with these parameters.
  • For most of the parameters, no additional properties are defined. The screenshot below shows the ‘Site’ parameter
  • Under ‘Property Name’ there is nothing defined.
  • However, if we look a the ‘No_of_networks’ parameter, there is an entry.

The options for this parameter are ‘predefined’. By clicking on the Array…, we can see what they are:

  • So, at the moment, I’ve defined the workflow to allow 1 or 2 isolated networks.
  • So, how does this control what is shown in the workflow console?
  • The parameters for isolated network #1 are always visible (what’s the point of deploying a bubble environment with no networks? )
  • However, let’s look at the parameters for those associated with test network 2

Network_2_name is shown below:

Using the ‘Show parameter input’ property, if the No_of_networks parameter is > 1, then show the Network_2_name parameter.

The same property is also set for Network_2_GW and Network_2_Mask

vRealize Automation

The XaaS blueprint in vRA is the mechanism that enables the end user to be able to call the vRO workflow which, in turn, calls the Powershell script.

The process of creating the XaaS blueprint is well documented, but in essence:

  • Click on Design -> XaaS -> XaaS Blueprints
  • Click New
  • Expand the vRealize Orchestrator folders to locate the vCO workflow that this blueprint will execute. Select it and click Next
  • Give the Blueprint an appropriate name, and if desired, set the version number. Click Next, Next and then Finish
  • Give the Blueprint an appropriate name, and if desired, set the version number. Click Next, Next and then Finish

The presentation we configured in vRO (drop-down menus, parameters being hidden/shown depending on others, etc) is reflected in vRA.

I did make one change in vRA (which I could have also done in vRO), but wanted to demonstrate the capability in vRA: I configured the Site parameter to also be a drop-down menu with pre-defined values.

How do we do that?

  • Under the Design tab, click the XaaS blueprint we just created
  • While we’re on this tab, we can also re-arrange the parameters and arrange them as we see fit
  • Click the Site parameter

Over on the right of the screen, locate the field Type and click the down arrow. Select Drop-down

  • A new tab will appear: Values. Click it
  • We could potentially use a vRO action to provide the values for this menu, but we’ll set them manually. Ensure that Predefined values is selected
  • The value is the actual value that will be assigned to this parameter. The Label is what will appear in the vRA form.

For eg, with the Powershell script above, the site could be one of 3 values, as shown below (non-relevant sections of script removed for simplicity)

1if ($param[0] -eq "NSX-1") {
2     Do stuff
4ElseIF ($param[0] -eq "NSX-2") {
5    Do different stuff
7ElseIF ($param[0] -eq "NSX-3")  {
8    Do other different stuff

So, the Values field needs to be “NSX-1”, “NSX-2” or “NSX-3”. However, this may not necessarily be clear to the user what these values actually signify.

So, we assign a label to each value, as shown in the screenshot below:

And we repeat this process for all required values, assigning appropriate labels in the process. When done, click Apply

  • Click Finish

Don’t forget to publish the blueprint and assign it to the correct vRA Service (there are plenty of resources online that outline this process)

What do we end up with?

If we go to the Catalog tab in vRA and click the required Service Catalog, we will find our newly created blueprint.

  • Click the Request button
  • We see a form not unlike the one we saw in vRO earlier.
  • Our network mask is a drop-down menu, containing the options defined in the vRO workflow
  • Our Site is a drop-down menu containing the options we defined in the vRA Blueprint form tab
  • As in the vRO form, setting the No of networks to 1 displays only the information relating to the 1st test network
  • However, setting it to 2 also displays the 2nd network information

The Best Way of Doing This?

It has been asked why I used PowerShell to create NSX objects via vRO & vRA, especially when there are other ways of doing the same thing:

  1. vRA has a native NSX plug-in and can be configured to do something similar using a standard (ie. non-XaaS) blueprints
  2. vRO can be configured to do the same thing using native REST API calls to NSX Manager

So, why Powershell?

My initial driver for doing this was to become more familiar with PowerShell (and specifically PowerNSX) while combining an interest in both NSX and automation via vRA.

Does this mean, then, that there isn’t a specific use case for something like what we’ve outlined above beyond simply self-education?

I don’t believe that is necessarily the case.

  1. Businesses (especially developers) may have a requirement (or at least a desire) to be able to deploy and tear down isolated, firewall-protected test networks for developing or testing applications
  2. These same developers are potentially fluent in PowerShell. However, they may not have the skills to develop native REST API calls to NSX Manager (PowerNSX abstracts API calls to NSX behind Powershell commands)
  3. These businesses may not have vRealize Automation and/or Orchestrator in place in their environment
    1. As outlined at the beginning, the process could be run by simply manually running the Powershell script and providing the appropriate parameters
  4. However, these businesses may have other automation tools inplace, such as
    1. Cisco UCS Director
    2. HP Helion
    3. An internally developed automation tool capable of running Powershell scripts

Hopefully, the process outlined above may assist in better understanding the various options available for automated deployment, and a better understanding of the technologies involved.

Ideas for improvement

Nothing tends to remain the same in IT for that long. Even processes that work still tend to be adjusted from time to time (for better or worse).

Areas that I’ve identified where things could be tweaked or changed could include the following:

  1. Rewriting the script to use native REST API calls to NSX Manager (the original driver for this was self education, after all)
  2. Improvements to error handling

Thanks to Tony Sangha and Brett Johnson for their assistance during the course of this project.