One of the new features of vSphere 7.0 Update 3 is that you can now manage NSX-T directly from the vSphere Client. In the new menu of the vSphere client UI, you will now find a section dedicated to NSX.
Opening this section currently brings up an NSX-T status information page. At this current stage, we are able to deploy new NSX-T instances, but existing NSX-T installations won’t be discovered.
Why is that?
As usual, a look at the Release Notes helps. There you’ll find the following statement for vCenter 7 Update 3:
You can see the vSphere Client NSX-T home page that enables the feature, but it does not work with NSX-T Data Center 3.1.x or earlier.
The most recent NSX-T version is 3.1.3 [as of 11/15/2021]. This means we have to wait for NSX-T version 3.2 until the integration works.
This blogpost was under embargo until 28th of September 2021 8:00am (PT) / 17:00 (CEST). The fact that you can read this now means that vSphere 7 Update 3 has (probably) already been released.
[Update 29th Sept 2021]: Download is not yet available. Maybe we need to wait until VMworld2021 next week.
What’s New
VMware vSphere 7 Update3 comes with a wide range of innovations. They can be categorized into the sections below:
Tanzu with Kubernetes
Lifecycle, Upgrade and Patching
Artificial Intelligence & Machine Learning
Resource Management
Availability & Resiliency
Security & Compliance
Guest OS and Workloads
Storage
Networking
vSphere Management & APIs
Another bunch of features goes into vSAN. But these features will be covered in an extra post.
Recently I activated Tanzu with NSX-T in my homelab. After some hurdles in the planning phase, the configuration worked fine and also north-south routing worked flawlessly. My edge nodes established BGP peering with the physical router and advertised new routes. New segments are immediately available without further configuratiom on the router.
One feature that distinguishes my lab from a production environment is that it doesn’t run 24/7. After the work is done, the whole cluster is shut down and the system is powered off. An idle cluster makes a lot of noise and consumes unnecessary energy.
Recently I booted the lab and observed that no communication with the router or DNS server was possible from my NSX segments. A perfect case for troubleshooting.
First I checked the Geneve tunnels between the transport nodes. Here everything was fine and every transport node was able to communicate with every other transport node. The root cause was quickly located in the edge nodes. Neither a reboot of the edges nor a vMotion to another host did improve the situation.
The Edges weren’t completely offline. They were administrable using the management network. Traceroute was working via T1 and T0 service routers up to the fastpath interface fp-eth0. From there, no packets were forwarded.
The interface fp-eth0 is connected to the distributed port group “Edge-Trunk” on vSwitch VDS-NSX. A quick check in the vSphere client showed that the uplink ports of both edges were blocked. Not in the “down” state, but blocked.
At this point, I would ask a customer what he has changed. But I am very sure that I did not make any changes to the system or the configuration. Yes, they all say that 😉
On October 20th 2020 VMware released NSX-T version 3.1 (release notes).
Upgrade from version 3.0
I’ll outline the process of upgrading from version 3.0.x to version 3.1. In the example shown, a base version 3.0.2 is upgraded, but the process is the same for all versions from 3.0.
Requirements
We’ll need an upgrade bundle (MUB) from VMware download site (login required).
Upgrade
First we need to login to NSX-T Manager. Go to section Lifecycle Management and select Upgrade. You’ll see your current version on the right. Start the process with Upgrade NSX.
