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.
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.
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.
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.
If anyone has a better way of adding code to posts, let me know Otherwise hopefully my journey helps someone along with theirs.