The topics “How do I get root access to the different NSX components” or “How can I find the root password” comes up quite often. For some components it’s already widely documented (for example NSX Manager) and for other components it’s rarely described (for example the NSX controllers). I also haven’t yet found a complete overview of how to get root access to the underlying Linux layer on all components. So I thought I’d put this information together here for the NSX versions 6.3 and 6.4.
Since upgrading to NSX 6.4, I get warnings for certain ESXi hosts because there is a VLAN and MTU mismatch. So I checked the vDS healthchecks and found the following error: VLAN 0 is not supported. But since we didn’t remove or add VLANs on the physical switches, I was very surprised. And VLAN 0 shouldn’t exist anyway. So, what is it about and why does the error suddenly occur?
We have recently upgraded from NSX-v 6.3.3 to NSX-v 6.4.3. The upgrade went well so far, but after the upgrade we noticed that the list of logical switches was no longer loaded correctly.
Depending on how we sorted the list, the list was either empty and the error message “Internal server error has occurred” was displayed or it happened while scrolling. In any case we couldn’t use the list with the logical switches anymore. And unfortunately the error message is quite useless.
So we went through the logs of the NSX Manager and found what we were looking for in the vsm.log.
Upgrading NIOC from version 2 to 3 is no big deal. But I’m writing this blog post because the official VMware documentation says that the upgrade to NIOC v3 is disruptive and that worried me.
We have only one dvSwitch in our virtual infrastructure and use vSAN and NSX. If this upgrade is really disruptive, we need to shut down all virtual machines before the upgrade process starts. And that would be a big deal for us and our customers.
Two of our vSAN clusters consist of VxRail S570 nodes with Intel X710 NICs. A few weeks ago the ESXi 6.5 hosts failed again and again. Not all at once but a different host every time. Failed means the host was displayed as “not responding” in the vSphere client and VMs stopped running and were restarted by vSphere Availability on other hosts.
Of course we thought of a network error at first, but on the physical upstream switches there were no related events in the logs and also all other hosts were not affected.
For high availability and performance reasons, it makes sense to run multiple vCloud Director cells. To do this, you can place a load balancer in front of it. And since we already use NSX for vCloud Director 9, it makes even more sense to use an edge gateway for load balancing.
However, there are a few pitfalls, for example with terminating HTTP connections, session persistence and especially with the VM Remote Console via the browser.
In my blog post I show you how to configure NSX and vCloud Director 9 and what to consider for this setup.
If you have already worked with IPv6 Default Routes in NSX 6.3, you may know the following problems: You set a static default route to ::/0, save your change and when you reload the page, the change is gone.
Or you want to upgrade the NSX Edge Gateways from version 6.2.x to 6.3.x and the Edge upgrade fails with an IPv6 error message.