WilliamLam.com

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

by // 2 Comments

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:

[Read more...]

Automated vSphere 7 and vSphere with Kubernetes Lab Deployment Script

by // 117 Comments

I know many of you have been asking me about my vSphere with Kubernetes automation script which I had been sharing snippets of on Twitter. For the past couple of weeks, I have been hard at work making the required changes between the vSphere 7 Beta and GA workflows, some additional testing and of course documentation. Hopefully the wait was worth it (I think it is) and if you enjoy the script or have benefited, please consider adding 🌟to the Github repo to show your support! Thanks and enjoy

The Github repository:

Before getting started, please carefully read through the requirements section along with the complete sample end-to-end execution if you are new to vSphere with Kubernetes. You will need to have a VMware Cloud Foundation (VCF) 4.0 license before you can get started and specifically an NSX-T Advance license which is one of the required parameters within the script. If you do not have access to a VCF 4 license, I strongly recommend taking part in the recent VMUG Advantage Homelab Group Buy effort which I had started to easily get access to the latest VMware releases along with a nice 15% discount!

The script supports deploying both a standard vSphere 7 environment with just VCSA, ESXi and vSAN as well as the complete solution which includes NSX-T to support vSphere with Kubernetes. For more details, please refer to the FAQ.

Automating the creation of NSX-T "Disconnected" Segments for DR testing on VMware Cloud on AWS 

by // 1 Comment

Disaster Recovery (DR) and Disaster Avoidance (DA) on VMware Cloud on AWS is still one of the most popular use case amongst our customers, just second to Datacenter Migration and Evacuation. The VMware Site Recovery service makes it extremely easy and cost effective for customers to protect their critical workloads without having to worry about the underlying infrastructure. Most often, the biggest cost of having a dedicated DR site is the on-going operational and maintenance cost of that infrastructure.

Most recently I have seen several requests come in where customers were looking to streamline their DR testing which is fantastic to hear. Just having a DR solution is not enough, you actually need to exercise it and verify that your workloads and applications are functioning as expected. Today, customers can verify that their applications are functioning as expected by creating NSX-T network segments that are "Disconnected" and then using a VM-based router to provide internal connectivity between these isolated environments.

Here is a screenshot of the VMware Cloud console and under the Networking & Security tab, when creating a new segment you can specify whether the segment is "Connected" (Routed) or "Disconnected".


Obviously, the NSX-T UI is just one way of creating a segment. In fact, most customers that have asked about this is wanting to do this via Automation which not only brings speed to testing but also consistency! With that, I have updated my NSX-T PowerShell Community Module for VMC to include two new updates. If you have never used this VMC module before, please take a look at the Getting Started guide here.

[Read more...]