Streamlining Network Selection in vRealize Automation: A Workaround Solution

VMware vRealize Automation (vRA) is a multi-cloud solution that allows businesses to automate and manage infrastructure across different clouds. One of the key features of vRA is the use of network profiles, which provide an abstraction layer for managing networks. A network profile is a pre-configured set of network settings that can be used to create virtual machines (VMs) and other network resources. These profiles are commonly used to simplify the process of assigning networks to VMs based on specific criteria such as application type, cluster, or data center.

However, some customers have hundreds of networks in their organization, which can make it difficult to tag and decide which deployment to use for a given network. In such cases, we have found it effective to enable end-users to choose the network to be used for a particular deployment, essentially bypassing the use of network profiles. This can be achieved by directly choosing the vCenter port group, which eliminates the need for an abstraction layer.

This workaround involves creating a cloud template that doesn’t have a network attached to the virtual machine (VM). Instead, a list of allowed networks for the cluster or data center where the VM will be deployed is displayed in a dropdown menu in the vRA Catalog items Custom Form. The user can choose which network they want to use from this list.

After the user submits their selection, a vRA REST API is used to get the name of the network they chose, and then the ID of that network is found in vRA. An event subscription is created to connect to the network configuration, and the ID of the network is returned to attach the VM to the selected network.
Here is a very simple example that selects a specific network using the extensibility task in Python using ABX:

PickSameNetwork
“`
def handler(context, inputs):

   outputs = {
   “networkSelectionIds”: [[[“1655ece4-2e3e-4d5b-af7a-d125429ade53”]]]
   }

   return outputs

“`

Here is code doing the same in JavaScript:

Then we need to add an event subscription that will return this network/networks to the requested deployment:

Beware of two points that can trip you up: Two tripping points:
– Make sure you return a 3-dimensional array for networkSelectionIds (note the `[[[` and `]]]`). This tripped me up when I was writing the example!
– Make sure the Extensibility Subscription is “Blocking.”, If it is not blocking, it is just “read-only” and will not use the output of the script for allocation.

While this approach can simplify the process of assigning networks for end-users, it has both pros and cons. One of the benefits is that it eliminates the need for complex tagging and network assignment rules. End-users can simply select the network they want to use from a dropdown list. Of course, it is still important to keep some network conventions in order to give the user the ability to choose the right network. Another benefit is that it provides greater flexibility in assigning networks based on specific requirements.

There are also some disadvantages to using this approach. One of the biggest drawbacks is that by eliminating the use of network profiles, the process of managing networks can become more complex. Additionally, it can be more complicated to implement, and it requires careful consideration of network naming conventions to ensure that the right network is selected.

Still, while not a standard approach or “best practice,” the ability to assign networks dynamically based on vCenter port group can be a useful workaround in certain situations.

Written by: Olga Balter, Cloud Automation Senior Engineer