Some time ago we had problems with the NSX Manager, had to deploy a new Manager appliance and restore a config backup. However, we were unable to manage Edge Gateways in the vCloud Director web interface after this work. Neither as Org Admin, nor as System Admins. In the Action menu the item “Edge Gateway Services” for configuring the network services was simply grayed out. Even a Re-deploy of the Edge Gateways didn’t help.
A few days after upgrading from vCloud Director 9.1 to 9.5, I encountered a strange issue. If someone was trying to launch a vApp or VM or trying to reconfigure existing VMs or vApps, it wasn’t possible. In the logs I could see the error message “Total available resources could not be determined for reservation” in combination with a long Java stack trace.
vCloud Director has been adding an Auto Discovery feature for VMs in version 8.20 and it’s available for some time now. It’s a cool feature that can simplify migrations, but in practice there are some pitfalls that can make things difficult. To be more concrete: It only works under certain conditions. Tom Fojta has written an article about this feature some time ago (Thanks, Tom). But I think some details are missing and that inspired me to post this.
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.