<Timestamp> In(182) nsx-opsagent[<NNNNNN>]: NSX <NNNNNN> - [nsx@6876 comp="nsx-esx" subcomp="opsagent" s2comp="nsxa" tid="<NNNNNN>" level="INFO"] [DoVifPortOperation] request=[opId:[sync-detach-0] op:[SYNC_DETACH_PORT(1002)] vif:[<UUID>] ls:[<UUID>] vmx:[/vmfs/volumes/<Datastore>/<VM directory>/<VMX filename>.vmx] lp:[<UUID>]]
VMware NSX
DO NOT register any Compute Manager during restore steps.
Compute Manager registration is contained in your backup and restored along with other configurations.
When NSX Manager gets connected to vCenter, it compares NSX portgroups on VC with its NSX segment, and adds or deletes NSX porgroups on VC to keep NSX segments synced.
As a fresh NSX Manager has no NSX segments before restoration, it deletes all the NSX portgroups on VC if you register the VC on NSX Manager.
NSX portgroups are created again during restore, but NSX ports on ESXi might get detached by periodic resync.
It cleans up ports that do not belong to a portgroup.
nsxaVim.log<Timestamp> Db(15) nsxaVim: [221882757]: DEBUG [resync] VM Vnic port <UUID> does not belong to a LSPG or security DVPG ...<Timestamp> In(14) nsxaVim: [221882757]: INFO [resync] resync doing VM crosscheck...<Timestamp> In(14) nsxaVim: [221882757]: INFO [resync] port2delete=[[]] port2detach=[[<List of port UUIDs to be detached>]] vnic2attach=[[]]
DO NOT register any compute manager during restore steps.
If you have done it, connect the affected vNICs to another potgroup and then connect them back to the original NSX portgroup.
Read the document and carefully follow the steps when you restore a backup.
The document does not suggest you register Compute Manager during the steps.