When you deploy a new vCenter Server without restoring from a file-based backup, the objects that NSX requires are lost or broken. You may observe the following symptoms:
Virtual Machines (VMs) are identified as brand-new objects, and historical VM representations are marked as disconnected or orphaned.
NSX Tags and Security Groups are broken, and tags assigned to VMs are purged after 30 minutes of disconnection.
Dynamic Security Groups empty out until VMs are manually re-tagged.
Distributed Firewall (DFW) rules remain intact but are unenforced because the underlying Security Groups have lost their VM members.
Transport Nodes (ESXi Hosts) are seen as permanently disconnected under the dead Compute Manager.
NSX Segments (Logical Switches) remain intact but are unsynchronized with the vCenter Distributed Switch (VDS).
VMware NSX
VMware vCenter Server
This issue occurs because replacing a vCenter Server without restoring from a native file-based backup is not a supported routine administrative action when that vCenter is acting as an NSX Compute Manager. The new vCenter Server generates entirely new Managed Object IDs (MOIDs) and UUIDs for every piece of inventory, which NSX relies on to track and apply policy to objects. Because the original IDs are destroyed, the built-in NSX "Replace Compute Manager" workflow becomes invalidated.
This is a condition that may occur in a VMware NSX environment.
If you experience this unrecoverable destruction of the vCenter database, the resulting data loss is considered expected product behavior and cannot be reversed by Support.