Welcome to the seventh installment of my NSX troubleshooting series. What I hope to do in these posts is share some of the common issues I run across from day to day. Each scenario will be a two-part post. The first will be an outline of the symptoms and problem statement along with bits of information from the environment. The second will be the solution, including the troubleshooting and investigation I did to get there.
The Scenario
As always, we’ll start with a brief problem statement:
“I’m in the process of decommissioning a remote location. I’m trying to convert the secondary NSX manager to a standalone, but it fails every time saying that universal objects need to be deleted. I’ve removed all of them and the error persists!”
Well, this seems odd. Let’s look at the environment and try to reproduce the issue to see what the exact error is.
It looks like the 172.19.10.40 NSX manager is currently in Transit mode. This means that it was removed as a secondary at some point but has not been converted to a standalone. This is the operation that is failing:
The exact error is the following:
“Unable to assign STANDALONE role. Universal objects of following types are present: LogicalSwitch,LogicalRouter,VNI Pool,TransportZone. Please delete these objects and try the operation again. NSX manager will remain in TRANSIT state until these objects are deleted.”
The error message seems clear that there are universal objects that still exist in the environment, but the customer insists that they’ve all been removed. Apparently there were several logical switches, a transport zone, universal DLR and a universal ESG. They were all successfully deleted.
After doing a few spot checks, it certainly appears that they are gone:
The only remaining logical switches are global objects, not universal.
The same goes for edges and transport zones – no universal objects remain. To better understand how we got to this point, I asked the customer for an account of what exactly was done:
- First, he disconnected the Secondary NSX Manager from the primary. This was successful, and it changed its role from Secondary to ‘Transit’.
- Next, he attempted to convert it to a ‘Standalone’ manager. This failed with the same error message mentioned earlier. This seemed valid, however, because those objects really did exist.
- At this point, he removed the remaining universal logical switches, edges and transport zone. These were all deleted successfully.
- The subsequent attempts to convert the manager to a ‘Standalone’ continues to fail with the same error message even though those objects are gone.
What’s Next?
I’ll post the solution in a day or two, but without giving too much away, pay close attention to the order of steps the customer did. Was this the correct process to move a secondary manager to the standalone role? Could this have contributed to the problem in some way?
The solution to scenario 7 is now posted. You can find it here.
How would you handle this scenario? Let me know! Please feel free to leave a comment below or via Twitter (@vswitchzero).
vswitchzero 