Nested Environments and Cloud Director / vRealize Automation 8
When I started my new job a Pure, one of the reasons why was to push into a new area that I’ve dabbled very little in. Automation and scripting/programming. I forgot how frustrating learning brand new things can be. That feeling of knowing exactly where you want to go, but not knowing how to get there. This post is not to report that I am now even close to knowledgeable on those. No, I’ve merely dipped my toes in. Still frustrated.
One of the issues I encountered was nested hosts and networks. I am working, among other things, on environments for sales engineers to do virtual POCs. While VMware does not officially support nested environments – and I really think they should in certain circumstances – They do have tools that allow you to bludgeon the settings to allow it. The main issue of course, is networking. NSX-V (or NSX for Datacenters in current marketing) is EOL in January 2022. While that can work, and does by manipulating the underlying Distributed Switch, this is not a long-term solution. I am also not sure what HOL will do since that is their current tool. The replacement, NSX-T doesn’t have great interoperability with vRA 8.x or Cloud Director 10.x. (I’m sure some would argue me on this) My reasoning on this is simple. While some objects can be created, you can’t configure even close to the full scope of options NSX-T makes available. Also, the APIs for NSX are inconsistent and difficult to work with in PowerShell, etc. even compared to others. While the API supports both Basic Auth and Bearer Token on NSX, to do anything meaningful in Cloud Director you have to post against it with Basic and get a Bearer Token to do the rest of the things. /Rant as a new guy off.
The Problem:
- For nested environments Mac Learning and Change needs to be set to enabled (Basically the same thing as changing the security policy on a Distributed Switch.
- We are working in “Policy” mode in NSX-T. While we could work in “Manager” mode, all indications point to VMware wanting you to use Policy mode as it is declarative vs imperative. I’m sure there are some other reasons too.
- While the rollout is automated of the vAPP, or Blueprint, we must figure out how to add this workflow after the deployment.
While the third script will work for vRealize Automation as well, I am only laying out what I did for Cloud Director (version 10.2.2) since that is what we currently setup. I also want to seriously thank the community for some of the code, poking me in right directions, and putting up with me while we worked to figure this out. It was a joint effort for sure.
In Cloud Director I have a test vApp I created to test this. This solution requires in addition to the main apps involved (Cloud Director, NSX-T, and supporting cast) vRealize Orchestrator. The latest supported version currently for Cloud Director is Orchestrator 8.3, so that is installed. All these scripts are written in JavaScript and refer to a main JS code written by Trisha Navarro. You can find that here. Her script paved the way for us to easily consume the APIs we needed to. I call to it using the name executeTransientRestOperation. Now we have a framework we can use to make API calls. This script needs to be setup as a scriptable action in vRealize Orchestrator. The first script we came up with was to auth to Cloud Director. You must post against an API endpoint with Basic Auth and it will return a Bearer token you can then use to do whatever.
https://github.com/it-muscle/automation/blob/main/getVcdToken.js
The second script takes that token received from the first and uses it to query Cloud Director for the network associated with a vAPP container name.
https://github.com/it-muscle/automation/blob/main/getNetworkIdFromVappName.js
The final script is where the magic all comes together. The script matches the NSX segment name with it’s UUID and then uses that to add the default segment profiles binding maps. By default they are already there, but you can’t change them without applying them and giving it a sub-UUID. Otherwise when you check it returns a 0 for maps. After those show up, this script will apply the mac profile you specify by name to it and returns you back to wherever you were. In my case I have stuck these all in the Instantiate vApp Workflow, so it kicks me back out to VCD. The whole thing is fast as well – as it should be. A 5 machine vAPP with network takes about 2ish minutes to deploy and return, even with this workflow attached. Here is the final script.
https://github.com/it-muscle/automation/blob/main/matchVappNetworkAndSwitchProfile.js
If anyone has a better way of adding code to posts, let me know Otherwise hopefully my journey helps someone along with theirs.