NSX-T Edge OVF property to automatically join NSX-T Management Plane

After publishing my vSphere 7 with Kubernetes automation lab deployment script, I was looking at my NSX-T Edge code which leverages the vSphere VM Keystroke API to automate the joining of the the NSX-T Edge to the NSX-T Management Plane. This technique is used to avoid the need for SSH access to both NSX-T Edge and Manager which is the official VMware method as outlined in the documentation for configuring the Edge.

This is certainly unfortunate as most customers normally disable SSH by default and only enable it for troubleshooting/debugging purposes. As far as I know, there are no remote NSX-T APIs for configuring an NSX-T Edge that has been deployed outside of NSX-T Manager, which has its own implications.

I recently had a chance to revisit some research I had made a note of when I had first started working with NSX-T. While inspecting the NSX-T Edge OVA, I found several OVF properties that begin with mp which per the description was referring to the NSX-T Manager. At the time, I was not able to figure out which the required combination of keys and values. Taking a closer look and poking around the appliance and logs, I was able to finally figure out the correct combination which turned out to be easy, once you knew what it was expecting.

To help demonstrate this functionality, I have created a basic PowerCLI script edge-auto-join-nsxt-management-plane.ps1 which uses information from your already deployed NSX-T Manager to automatically deploy the desired number of NSX-T Edge(s) which will automatically join the NSX-T Management Plane upon initial setup.

The way this works is that the following four OVF properties must be filled as part of the NSX-T Edge deployment:

• mpIp - IP Address of your NSX-T Manager (FQDN will not work)
• mpUser - User to join the NSX-T Edge, which is the admin account of the NSX-T Manager
• mpPassword - Password to admin user of the NSX-T Manager
• mpThumbprint - SHA256 Thumbprint of the NSX-T Manager

These values are then passed down to the NSX-T Edge which will attempt to join the NSX-T Management Plane. This took a few attempt and a useful log in the NSX-T Edge to look at is /var/log/join_mp.log which gave more details on some of the failures. I should also mention that these OVF properties are NOT new in latest NSX-T 3.0 release and I have seen them for several releases now, so it should be possible to use this technique with earlier releases of NSX-T.

If everything was configured correctly, once the NSX-T Edge has fully initialized, you should see it automatically appear under the Edge Transport Nodes section of the NSX-T Manager.

I still need to do a bit more testing before I can incorporate this new technique back into my vSphere 7 with Kubernetes deployment script, but this will certainly make the automation more robust and not have to rely on sending keystrokes into the VM which has worked for a number of years now. Lastly, folks with a keen eye may have also notice other mp variables, I believe this exact same technique can be used to automatically stand up multiple NSX-T Managers to form a highly available NSX-T Control Plane as the NSX-T Controllers have been consolidated into the NSX-T Manager component. This maybe another topic to explore in the future, but I have some ideas of how this should work.