Virtual Machines Lose Network Access After vMotion Between NSX Logical Switches
search cancel

Virtual Machines Lose Network Access After vMotion Between NSX Logical Switches

book

Article ID: 443969

calendar_today

Updated On:

Products

VMware vSphere ESXi

Issue/Introduction

After performing a vMotion from one logical switch to another logical switch (cross-network migrations. NOTE: This does not happen if there is a cross-cluster but with the same logical switch between source and destination), Virtual Machines (VMs) lose network access after a DRS or manual vMotion.

The following error is observed in the vmkernel.log:

2026-05-16T17:37:11.904Z In(182) vmkernel: cpu77:2099000)kcp: KCP_DeletePort:958: [nsx@6876 comp="nsx-esx" subcomp="kcp"]Port ########-####-####-####-########f2a7 is cleared and blocked

There will be similar NSX log entries:

  1. On the NSX Manager under /var/log/proton/nsxapi.log
    2026-04-23T04:57:34.644Z  INFO workerTaskExecutor-1-20 LSPInterVtepUtilsImpl 77557 FABRIC [nsx@6876 comp="nsx-manager" level="INFO" subcomp="manager"] LspInterVtep flag true logicalPort LogicalPort [id=########-####-####-####-########f2a7, intentPath=/infra/segments/########-####-####-####-########f61a/ports/default:########-####-####-####-########f2a7, logicalPortState=UP, ephemeral=true, logicalSwitchId=LogicalSwitch/########-####-####-####-########eff9, transportZoneId=TransportZone/########-####-####-####-########aeba, transportZoneType=VLAN, attachmentId=########-####-####-####-########c42a, attachmentType=vif, internalPortAttachment=null, switchingProfileIds=[], switchMode=STANDARD, extraConfigs=null, systemExtraConfigs=null, internalId=, initState=null, tags=null, pendingConfigFromHostd=true, addressBindings=null, ignoreAddressBindings=null, isIndependentVifPort=false, context=null, isEsxVmk=false, isDvport=false, skipDefaultProfiles=[]],  logicalSwitch LogicalSwitch [id=LogicalSwitch/########-####-####-####-########eff9, name=########0.24, segmentPath=/infra/segments/########-####-####-####-########f61a, switchType=DEFAULT, transportZoneId=TransportZone/########-####-####-####-########aeba, vlan=##12, adminState=UP, switchingProfileIds=null, switchMode=STANDARD, switchType=DEFAULT, uplinkTeamingPolicyName=null, extraConfigs=[  ], originId=null, originType=null, org=null, project=null, vpc=null, skipDefaultProfile=[]],   edgeTransportNodes []
  2. On the NSX Manager under /var/log/proton/nsxapi.log
    2026-05-02T21:20:54.105Z  INFO workerTaskExecutor-1-10 LSPInterVtepUtilsImpl 77557 FABRIC [nsx@6876 comp="nsx-manager" level="INFO" subcomp="manager"] LspInterVtep flag true logicalPort LogicalPort [id=########-####-####-####-########4e62, intentPath=/infra/segments/########-####-####-####-########46db/ports/default:########-####-####-####-########4e62, logicalPortState=UP, ephemeral=true, logicalSwitchId=LogicalSwitch/########-####-####-####-########f6ef, transportZoneId=TransportZone/########-####-####-####-########aeba, transportZoneType=VLAN, attachmentId=########-####-####-####-########c42a, attachmentType=vif, internalPortAttachment=null, switchingProfileIds=[], switchMode=STANDARD, extraConfigs=null, systemExtraConfigs=null, internalId=, initState=null, tags=null, pendingConfigFromHostd=true, addressBindings=null, ignoreAddressBindings=null, isIndependentVifPort=false, context=null, isEsxVmk=false, isDvport=false, skipDefaultProfiles=[]],  logicalSwitch LogicalSwitch [id=LogicalSwitch/########-####-####-####-#########f6ef, name=########-####-####-####-########1645, segmentPath=/infra/segments/########-####-####-####-########46db, switchType=DEFAULT, transportZoneId=TransportZone/########-####-####-####-########aeba, vlan=##34, adminState=UP, switchingProfileIds=null, switchMode=STANDARD, switchType=DEFAULT, uplinkTeamingPolicyName=null, extraConfigs=[  ], originId=null, originType=null, org=null, project=null, vpc=null, skipDefaultProfile=[]],   edgeTransportNodes []
  3. Observe that the logical switch ID has changed

    ########-####-####-####-########eff9   ->  ########-####-####-####-########f6ef

Environment

NSX

Cause

When a cross-LS vMotion (########-####-####-####-########eff9 -> ########-####-####-####-########f6ef) is performed it succeeds, but due to a bug, there will be rollback cache details on the host including details of the older logical switch that the VM had moved from. This is done in case the migration fails and needs to be rolled back.

  • Log statements showing Logical Switch migration:

    2026-05-09T21:03:08.485Z In(182) nsx-opsagent[###8760]: NSX ###8760 - [nsx@6876 comp="nsx-esx" subcomp="opsagent" s2comp="nsxa" tid="###9937" level="INFO"] [HandlePriorAttachedPort] handling prior attachment for vif: ls:[########-####-####-####-########f2a7] lp:[########-####-####-####-########cd5c] tz:[########-####-####-####-########aeba]

2026-05-09T21:03:08.486Z In(182) nsx-opsagent[###8760]: NSX ###8760 - [nsx@6876 comp="nsx-esx" subcomp="opsagent" s2comp="nsxa" tid="###9937" level="INFO"] [HandlePriorAttachedPort] cleared vif [########-####-####-####-########0d1f] on prior attached dvport [########-####-####-####-########cd5c] on ls [########-####-####-####-########eff9] in zone [########-####-####-####-########aeba]


  • When DRS performs a standard vMotion to another host
    • The source host processes the detach for the DRS vMotion
    • The stale cache from the LS to LS migration above causes the manager to incorrectly assumed the cross-LS migration was failing and attempts to rollback the VM to the old Logical Switch, which blocks the port.

  • Log statements showing the rollback exercised:

    2026-05-16T17:37:11.841Z In(182) nsx-opsagent[###8760]: NSX ###8760 - [nsx@6876 comp="nsx-esx" subcomp="opsagent" s2comp="nsxa" tid="###9937" level="INFO"] [PortOp] Inside cleanup prior port, about to clear vif
  • Log statements showing the port block

    2026-05-16T17:37:11.653Z In(182) vmkernel: cpu77:2099000)NetDVS: 9695: Property com.vmware.common.port.block, propType=0x8 (0x8), skip update for port ########-####-####-####-########cd5c
2026-05-16T17:37:11.904Z In(182) vmkernel: cpu77:2099000)kcp: KCP_DeletePort:958: [nsx@6876 comp="nsx-esx" subcomp="kcp"]Port #####8917 is cleared and blocked

Resolution

For future migrations:

  • Immediately after the cross-network vMotion completes, open an SSH session to the target ESXi host.
  • Restart the nsx-opsagent service to clear the cache and ensure subsequent vMotions do not impact connectivity:

For currently affected VMs:

  • Manually vMotion the affected VM back to the ESXi host where it previously had network connectivity.
  • Once connectivity is verified as resumed, open an SSH session to that specific ESXi host.
    • Restart the nsx-opsagent service on that host to clear the cache:
      /etc/init.d/nsx-opsagent restart

Additional Information

References:
NSX segment backed VM switch port blocked due to stale nsx-opsagent cache

 

Powered by Wolken Software