VMs Lose Network Connectivity During SRM Test at “Create Writable Storage Snapshot and Test Network”
search cancel

VMs Lose Network Connectivity During SRM Test at “Create Writable Storage Snapshot and Test Network”

book

Article ID: 428501

calendar_today

Updated On:

Products

VMware Live Recovery

Issue/Introduction

Symptoms

  • Virtual machines lose network connectivity during an SRM Test Recovery.

  • The issue occurs at the step “Create Writable Storage Snapshot and Test Network.”

  • The guest OS shows the network as disconnected.

  • In vSphere, the vNIC still appears connected.

  • Reconnecting the vNIC fails.

  • Network connectivity is restored only after switching the VM to another port group.

  • The issue affects only one NSX segment and one port group within that segment.

Environment

VMware Site Recovery Manager 8.X
VMware Live Recovery 9.x

Cause

  • SRM did not directly modify the protected VM, but the SRM test mostly triggered NSX control-plane operations on the segment, causing NSX logical port (VIF) reprogramming and a temporary ESXi data-path disruption that resulted in guest OS network connectivity loss while the vNIC remained connected in vSphere.
  • The following log events indicate NSX logical port disablement along with Distributed Virtual Switch (DVS) port block events.

/var/run/log/vmkernel.log :

2026-01-14T09:29:24.678Z In(182) vmkernel: cpu40:2116913)kcp: KCP_DeletePort:951: [nsx@6876 comp="nsx-esx" subcomp="kcp"]Port 201326705 is cleared and blocked
2026-01-14T09:29:24.788Z In(182) vmkernel: cpu40:2116913)FlowCache.fc: FC_ClearPortData:488: [nsx@6876 comp="nsx-esx"]Cleared portData on port 0x#########, portData:0x############
2026-01-14T09:29:24.788Z In(182) vmkernel: cpu40:2116913)FlowCache.fc: FC_PortCacheDisable:2490: [nsx@6876 comp="nsx-esx"]FC Port Disable 0x#########
2026-01-14T09:29:24.788Z In(182) vmkernel: cpu40:2116913)FlowCache.fc: FCInvalidatePortEntity:384: [nsx@6876 comp="nsx-esx"]FC unref inval port 0x#######

2026-01-14T09:29:24.788Z In(182) vmkernel: cpu3:2116946)nsxt-latency: LATSwitchDelayedDeactivateCB:287: [nsx@6876 comp="nsx-esx" subcomp="latency"]Portset DvsPortset-4: async  deactivation starts
2026-01-14T09:29:24.795Z In(182) vmkernel: cpu3:2116946)nsxt-latency: LATSwitchDelayedDeactivateCB:296: [nsx@6876 comp="nsx-esx" subcomp="latency"]Portset DvsPortset-4: succeeded in deactivation.

/var/run/log/hostd.log:

2026-01-14T09:29:24.512Z In(166) Hostd[2099622]: [Originator@6876 sub=Vimsvc.ha-eventmgr] Event 10220 : The dvPort ########-####-####-####-############ was blocked in the vSphere Distributed Switch  in ha-datacenter. It was in Unknown state before.
2026-01-14T09:29:24.635Z In(166) Hostd[2099620]: [Originator@6876 sub=Vimsvc.ha-eventmgr] Event 10221 : The dvPort ########-####-####-####-############ was blocked in the vSphere Distributed Switch  in ha-datacenter. It was in Unknown state before .

Resolution

 To resolve this issue and prevent disruptions to production workloads during recovery testing:

  1. Validate Physical Network: Engage your physical network team to ensure the underlying network configuration is stable and supports the required VLAN/MTU settings for NSX.
  2. Use Dedicated Segments: Configure dedicated NSX segments and port groups exclusively for SRM test environments.
  3. Ensure Network Isolation: Maintain a strict separation between production NSX segments and SRM test recovery plans. Isolating the test network ensures that control-plane operations do not impact live traffic during SRM test execution.
Powered by Wolken Software