We had a project where we replace the old hosts with the new ones and use the same IP addresses. Everything was fine until we put the new hosts back into the cluster and NSX preparations task kick in. Then NSX manager gives as validation error. It states: “26210: Node duo-11 with 10.10.10.1 already exists”.
I suppose somewhere in a database there is still a reference to the previous configuration, that causes a conflict. Correct and error free removal procedure should be first remove NSX components from NSX manager UI before removing from vCenter.
In my specific failure scenario I resolved this with these steps:
- Check if node is really orphaned. You can use NSX global search by hostname or ID.
2. Get the orphaned node’s ID.
To get the “real” ID, the easiest solution is to just use the Global Search feature in the NSX UI. I just searched for the former hostname of the Node and there was a entry for a transport node with the exact same hostname. Upon expanding the result NSX will tell you the ID.
3. Check with API call if the Node is still existing in the full list of all transport nodes (Full text search in the response for the ESXi Management IP or the fqdn). This returned zero results. I use postman for convenience.
GET https://nsx-fqdn/api/v1/transport-nodes/
4. Check on the ESXi host if all NSX components are fully uninstalled. You can do this via a SSH connection to the ESXi host and invoking nsxcli. If this already fails, NSX components are removed. If not, delete them via the command del nsx.
5. Force delete node with API call.
DELETE https://nsx-fqdn/api/v1/transport-nodes/node_id?force=true&unprepare_host=false
After removing the old entry, the installation of the NSX components went through and succeeded.
Leave a Reply