Author: Adrian Page 6 of 13

NSX-T setup with Edge single NIC uplink profile and static routing

In last year’s VMware homelab NSX series, I’ve showed howto setup a NSX setup with BGP and later with OSPF. This time, I’m going to deploy and configure NSX-T with a static routing setup using single Edge uplinks. NSX-T is used 3.2.2 in the lab environment.

In this lab, we have two ToR switches, configured with VRRP. The ESXi server is physically connected with one uplink “Uplink1” to ToR-1 and with another uplink “Uplink2” to ToR-2.

The Edge Node VM design in the environment is driven by the following goals:

  • 1 virtual uplink used (redundancy is provided by ESXi pNICs)
  • A single N-VDS per Edge node carrying both overlay and external traffic

The Tier-0 gateway is configured with a HA VIP and sets it default route to the ToR virtual router group IP address. The ToR routes all traffic destined for our Overlay segment to the Tier-0 HA VIP.

The overall topology can be seen in the following diagram.

Delete a failed Aria Automation deployment using a day 2 operation with an API call

Recently I was tasked to create some kind of instant auto-removal of failed Aria Automation deployments for a given Cloud template.

This can be achieved through leveraging a custom day 2 operation using the Aria Automation Deployment API request controller. For this particular use-case we execute the deployment resource “delete” action.

The required REST call for this resource action is: POST /deployment/api/requests/{requestId}
The JSON body must be specified as follows: { “actionId”: “Deployment.Delete”}

To execute this action every time a deployment fails, we use an Extensibility subscription to be automatically triggered if the status of the deployment is “FAILED” and the event type equals “CREATE_DEPLOYMENT”.

In this example we will use Aria Orchestrator to create the custom action.

Setting up a multi-cloud deployments in Aria Automation Assembler

Recently, I wanted to demonstrate Aria Automation’s multi-cloud capabilities. Therefore I wanted to use the official tutorial available on the VMware documentation web site as a basis (https://docs.vmware.com/en/vRealize-Automation/8.11/Using-and-Managing-Cloud-Assembly/GUID-6EC5AFE5-3C18-4F68-A7E3-82ADD4490002.html). In this tutorial we deploy the same cloud template to more than one cloud provider, in this case AWS and Microsoft Azure.

Setting up the infrastructure on AWS and Azure (labeled “part 1” in the official tutorial) works as described there (except that you have to select other image mappings), also the creation of the Aria Automation example project (labeled “part 2” in the official tutorial) works as described, but I had problems with the Automation Assembler templates to deploy the basic cloud template and the expanded cloud template (labeled “part 3” in the official tutorial).

Thus I’ve played around a bit and came up with two working cloud templates.

Customizing a vSphere VM guest OS using Aria Automation cloudConfig

We can install a guest operating system in a VM and control guest operating system customisation for VMs by either running commands directly or, if deploying to vSphere-based cloud platforms, through customisation specifications.

In Aria Automation these commands are defined in a so-called cloudConfig resource property in the cloud template code which holds the commands that should be run. For customisation specifications on the other hand, a property in the cloud template code references a vSphere customisation specification by name.

In this post I’m going to show how to leverage Aria Automation cloudConfig to customise Ubuntu 22 and Windows Server 2022 VMs. Such customisation could include:

  • Set the hostname
  • Set the timezone
  • Configure the network adapter
  • Partition, format, mount hard disks
  • Run arbitrary commands (e.g. join a domain)

Consuming the NSX-T API with Aria Automation and Orchestrator

Recently, I was asked by a customer to deploy a custom NSX-T firewalling solution for their virtual machines, where virtual machines owned by an Aria Automation user are allowed to communicate with virtual machines of the same user. The solution leverages NSX-T firewall rules based on groups, where the group membership is defined based on NSX-T tags attached to a virtual machine.

To achieve the custom tagging of virtual machines in NSX-T during the VM deployment phase in Aria Automation, I developed a Orchestrator workflow leveraging the capabilities of the NSX-T API.

In this blog post, I’ll demonstrate how to use the NSX-T API from Orchestrator.

Page 6 of 13

All your base are belong to us.