vCenter Server vMotion hangs at 84% with destination host Not Responding
Article ID: 437748
Updated On:
Products
Issue/Introduction
When performing a live vMotion of the vCenter Server Appliance (VCSA) to another host in the cluster, the following symptoms are observed:
- The migration task hangs at 84% completion.
- The destination ESXi host enters a Not Responding state in the vCenter inventory.
- Other virtual machines migrate successfully; the issue is isolated to the vCenter VM.
Environment
VMware vSphere ESXi 8.x
VMware vCenter vCenter 8.x
Cause
This issue occurs due to network hair pinning on an ESXi Standard vSwitch (vSS). When the ESXi Management Network (vmk0) and the vCenter VM network are on the same IP subnet but reside on isolated standard switches with separate physical uplinks, a loop-prevention mechanism is triggered.
During the final switchover phase of vMotion (84%), the vCenter VM resumes on the destination host. The host's management agent (vpxa) attempts to send heartbeat traffic (UDP 902) to vCenter. Because the networks are on the same subnet but different switches, the packet leaves one physical uplink and enters another. The ESXi host recognizes the source MAC address as its own local vmk0 and drops the packet to prevent a network loop. Consequently, heartbeats are lost, and the host disconnects.
Resolution
To resolve this issue, implement one of the following architectural changes to prevent physical uplink hair pinning:
Option 1: Single vSwitch Topology
Reconfigure the ESXi hosts so that both the Management Network (vmk0) and the vCenter Server VM Port Group are attached to the same virtual switch (either a single Standard vSwitch or a vSphere Distributed Switch).
Option 2: Layer 3 Segmentation
Ensure the ESXi Management Network and the vCenter VM Network reside on distinct IP subnets and VLANs. This forces traffic through a Layer 3 gateway, which modifies the source MAC address and bypasses the loop-prevention check.
Feedback
