VMs (including vCenter) disconnected after vMotion to any host
search cancel

VMs (including vCenter) disconnected after vMotion to any host

book

Article ID: 418832

calendar_today

Updated On:

Products

VMware vCenter Server

Issue/Introduction

A given VM, including the vCenter VM, becomes disconnected after being migrated or a vMotion to any other host in an environment.

The issue is consistent and happens after a migration or vMotion 100% of the time, though not all VMs may be impacted at the same time.

The VMs may come back on network after 2 to 3 minutes.

Note: If the issue is intermittent, or only disconnects after a vMotion on some occasions, this KB may still apply, but the following KB may be more applicable: VMs intermittently lose network connections after vMotion

Environment

vCenter (all versions)

VMware ESXi 

Cause

After a vMotion operation, the receiving host sends a Reverse ARP (RARP) packet on behalf of the VM to update the rest of the network of the VM's new location.

In some cases, although the RARP can be confirmed as leaving the host as expected via packet captures, the updated VM location information is not propagated through the network by the physical switch and so any further communication to/from the VM is dropped.

The physical switch infrastructure is failing to update its MAC address table (CAM table) immediately upon receiving the Reverse ARP (RARP) packets sent by the destination ESXi host. Thus the switch still associates the VM's MAC address with the source host's physical port and traffic is misdirected to the source host. The source host drops this traffic as the VM is no longer a resident.

Resolution

This issue is caused by a failure or significant delay in MAC address learning on the physical switchport. To resolve this, engage the physical networking team to investigate the switch's learning behavior and ensure timely address updates.

Additional Information

You can use the built-in pktcap-uw tool to set up a capture on the destination host at the time of a vMotion to ensure the RARP packet is being sent out, though it may become complicated to preemptively set up the capture as variables such as the uplink the VM will use after the vMotion may vary based on configurations. That said, the below KB details the pktcap-uw tool for reference, but it may be worthwhile to create a case with Broadcom Support for assistance: Creating and managing Broadcom support request (SR) cases

NOTE: To see RARP packets specifically, the packet capture will need to be exported to a packet capture file (.pcapng) and then reviewed with a tool such as Wireshark, filtering for "arp" packets in the tool itself rather than in the capture command: