Note: Ensure a full, image-level backup of the affected virtual machine is completed.
Option 1:
- Forcefully delete the corrupted inventory records via the NSX Management API
curl -k -u admin: <password> -X DELETE "https://127.0.0.1/api/v1/fabric/virtual-machines/########################"
- Run the following command in NSX Manager to restart the inventory synchronization service and force an immediate polling cycle:
service cm-inventory restart
- Wait for 5 minutes for the polling cycle to complete and verify if the stale VMs are removed from NSX manager.
Option 2:
- Remove the Virtual machine from the Inventory
In the vSphere Client, right-click the active virtual machine and select Remove from Inventory. Critical: Do not select "Delete from Disk"
- Run the following command in NSX Manager to restart the inventory synchronization service and force an immediate polling cycle:
service cm-inventory restart
- Navigate to Inventory > Virtual Machines in the NSX Manager UI and verify the duplicate entries have been successfully purged.
- Return to the vSphere Client, navigate to the datastore containing the virtual machine, right-click the
.vmx file, and select Register VM. Power on the virtual machine.
Note: If the re-registered virtual machine displays its base UUID instead of its friendly name, manually rename the virtual machine in the vSphere Client.
If the stale virtual machine entries persist in the NSX Manager inventory after executing these steps Contact Broadcom support to manually clear the internal database constraints.