VMs lose network connectivity during backup restoration of the VMs

Products

VMware NSX

Issue/Introduction

During restoration of the virtual machines using third-party backup tools, a few virtual machines experienced a network interruption.
This occurred because the affected VMs were restored to a different subnet while retaining their exact original VIF (Virtual Interface) IDs.
Behavior is observed on NSX Segments including NSX on DvPG deployments.
The new VM’s network device spec carries the original VM's NSX VIF:
For Restored vm
VIF ID 95a91c59-#####-#####3
Logical switch iD b60e###-#####-##
hostd.log:2026-08-17T09:10:07.905Z Db(167) Hostd[2103485]: [Originator@6876 sub=Vmsvc.vm:/vmfs/volumes/vsan:.../<Hostname after restore>.vmx opID=######... user=vpxuser:ZONE1-####\svc.coh.####]
Opaque network changes in deviceSpec: { [-4->b60e###-#####-##:nsx.LogicalSwitch:95a91c59-#####-#####3]}
hostd.log:2026-08-17T09:10:08.653Z Db(167) Hostd[2103485]: [Originator@6876 sub=Vmsvc.vm:/vmfs/volumes/vsan:.../<Hostname after restore>.vmx opID=###### ...]
VmReconfigure: [-4 attached to vif:95a91c59-#####-#####3 net:b60e###-#####-##:nsx.LogicalSwitch]]
At the moment of restore, the replayed VIF UUID (95a91c59) was still bound to a live Logical Port in NSX (original working VM)
hostd.log:2026-08-17T09:02:05.732Z In(166) Hostd[2103400]: [Originator@6876 sub=Vmsvc.vm:/vmfs/volumes/vsan:.../<Hostname after restore>.vmx opID=WorkQueue-####### sid=5######0 user=vpxuser:<no user>]
Updated active set of monitored objects for VM '37'. total: 3, added: 0, removed: 0
Manager-side, the attach request for the restore collides with an existing attachment:
syslog:2026-08-17T09:10:07.906Z ... [comp="nsx-manager" subcomp="manager"]
VifMsgHandler.BEGIN: Received VifMsg [null:null]: "operation: ATTACH_VIF_TO_PORT
type: REQUEST
vif_attachment {
vif_uuid: "95a91c59-#####-#####3"
logical_switch_uuid: "b60e###-#####-##"
logical_port_uuid: ""
host_id: "2a####-d###-##-a###"
vmx_path: "/vmfs/volumes/vsan:.../<Hostname after restore>.vmx"
host_operation_id: "1cce####-01-##-####-6-7"
}"
syslog:2026-08-17T09:10:08.401Z ... [subcomp="manager"]
Created a new port for VNIC attaching: LogicalPort [id=663###-##-b##-###, ...,
logicalSwitchId=LogicalSwitch/b60e###-#####-##, ..., attachmentId=95a91c59-#####-#####3, ...]
syslog:2026-08-17T09:10:08.401Z ... [subcomp="manager"]
Deleted LogicalPortAttachers of b60e###-#####-## after 2####-d#######:[.../<Hostname after restore>.vmx] removed for VIF 95a91c59-#####-#####3
syslog-2026-08-17T09:10:08.506Z ... [subcomp="manager"]
Deleted LogicalPort InternalLogicalPort/b####-7######### from internal store
syslog-2026-08-17T09:10:08.506Z ... [subcomp="manager"]
Moved attachment from LogicalPort [id=b####-4b###-c28c####, intentPath=/infra/segments/#.#.#.#/ports/default:b429a2b2-...,
logicalSwitchId=LogicalSwitch/3d##-6##-4##-9###, ..., attachmentId=95a91c59-#####-#####3, ...]
to LogicalPort [id=6###-8##-4##b##-1e##, intentPath=/infra/segments/#.#.#.#/ports/default:66376be3-...,
logicalSwitchId=LogicalSwitch/b60e###-#####-##,, ..., attachmentId=95a91c59-#####-#####3, ...]
syslog-2026-08-17T09:10:08.506Z ... [subcomp="manager"]
Creating LogicalPortSendDetachMsgToTNActivity to send a port-detach message to TransportNode [[b##-67e3-##d-b##]] for detaching the port [b4###.######]...
The vNIC attach/collision sequence occurs while the restored VM remains powered off
hostd.log:2026-08-17T09:10:07.903Z ... Checking for all objects accessibility (VM's current state: VM_STATE_CREATING, stable? false, ...)
hostd.log:2026-08-17T09:10:08.658Z ... State Transition (VM_STATE_INITIALIZING -> VM_STATE_OFF)
hostd.log:2026-08-17T09:10:08.663Z ... UpdatePortReconfig: _opaqueNetworkUsedAfter: { [4000->b60e###-#####-##-...:95a91c59-#####-#####3...]}
hostd.log:2026-08-17T09:10:08.720Z ... convert {externalId:95a91c59-#####-#####3-..., onId:b60e###-#####-##...} to {port:66376be3-..., portgroup:dvportgroup-1267, ...}
hostd.log:2026-08-17T09:10:19.450Z ... State Transition (VM_STATE_OFF -> VM_STATE_RECONFIGURING)
hostd.log:2026-08-17T09:10:19.505Z ... State Transition (VM_STATE_RECONFIGURING -> VM_STATE_OFF)
hostd.log:2026-08-17T09:10:29.740Z ... State Transition (VM_STATE_OFF -> VM_STATE_RECONFIGURING)

Environment

VMware NSX

Cause

The network interruption occurred because a VM was restored into a different subnet while retaining its exact same VIF ID. From an NSX perspective, VIF IDs must remain strictly unique.

Any new event triggering on the newly restored VIF ID (for example, a change in segment, even when a VM is powered off) is treated as a state change. According to the designed NSX workflow, this state change forces the original VM to drop its network connectivity. In this instance, the broken VM experienced instant issues despite being powered off because attaching it to a new segment forced the NIC to be realized.

Resolution

Permanent solution will be in a future release of 9.x.

Workaround Options:

Option 1 (Recommended): Restore the virtual machine without network adapters or configuration details, then manually add and configure the network after the restore is complete. This approach separates the process into clear, chronological steps for better usability.
Note: Ensure that there is no network information present during the restore as presence of duplicate network parameters (ex: MAC Address, VIF ID) could lead to a network outage.
Option 2: Configure your backup/restore solution so that it does not copy the VIF properties when copying the VMX file, provided this is feasible within your platform's capabilities.
Option 3: If the original VM remains in the inventory, you must restore it to a host that does not contain that VM.

Additional Information

For defect tracking, users should subscribe to this article to receive updates on the permanent fix status.