ESXi vMotion causes guest VM to acquire a different MAC, triggering duplicate MAC and DHCP conflicts

Environment

vSphere 7.0u3 environment with multiple ESXi hosts (HPE ProLiant Gen10). Standard vSwitch and distributed vSwitch in use; vMotion configured on dedicated VLAN. VMs are a mix of autogenerated MACs and a small number with manually assigned static MAC reservations via vCenter. DHCP server is ISC DHCP on a routed management VLAN.

Symptoms

After a vMotion event, some VMs become unreachable by their IPv4 address. Physical switches report MAC flapping between two access ports. DHCP leases show the same IP assigned to two different MACs intermittently. The affected VM's guest OS reports its NIC still configured with the old MAC, but the hypervisor inventory and network show a different MAC in use.

Observations

vCenter shows vMotion completed successfully. Extracted vmware.log from the VM's folder shows the VM registered with a new MAC after the vMotion timestamp. Inspecting the VM's .vmx on the destination host shows ethernet0.addressType set to 'generated' with a different ethernet0.address than the source host's inventory. No recent changes to MAC pools noted, but there are multiple MAC pools across clusters. Rebooting the VM forces the guest to use the new MAC consistently, but this causes temporary outage. Removing and re-adding the virtual NIC in vCenter also briefly resolves the conflict for some VMs.

Already attempted

Rebooted the affected VMs (service disruption acceptable for a subset) — conflicts cleared until next vMotion. Attempted to reassign static MACs via vCenter GUI for a test VM (manually setting ethernetX.address), which fixed that VM persistently. Reviewed vCenter event logs and MAC pool ranges; no overlap found but exact pool mappings between clusters are complex. Temporarily disabled automated DRS migrations for the test cluster to prevent vMotion; problem stops while DRS off.

Question

What mechanisms in vSphere could cause a VM's effective MAC to change during vMotion, and what are the safest operational controls to prevent MAC reassignment and resulting network duplicates without disabling vMotion entirely?

Post timeline

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses

AI DIAGNOSTICS

Incident analysis

Updated 1w ago• Trouble ID

Most likely causes

vCenter/ESXi MAC pool allocation policy or configuration has inconsistent ranges across clusters, causing vCenter to reassign a generated MAC on destination. 85%

VM configuration divergence (corrupt or inconsistent .vmx) leading destination host to recreate NIC with a new generated MAC. 40%

Automated processes or orchestration tooling that reconfigures VMs during/after migration (cloud-init, guest customizers, orchestration hooks). 20%

Summary

VM MACs in vSphere should remain stable across vMotion. A change implies that either the VM's configuration on the destination host was modified at migration time (e.g., addressType changed/overridden), MAC pool allocations overlapped or vCenter/host applied a new generated MAC because the original was considered invalid or already assigned elsewhere. Another possibility is that a template or clone configuration with transient MACs was applied, or the VMX was inconsistent between hosts. Manual MAC assignment is the most reliable way to enforce a stable MAC but requires inventory changes.

Suggested Fixes

Diagnostic step 1

Audit MAC address allocation: in vCenter, check all MAC pools and ensure ranges do not overlap across clusters. If using multiple MAC pools, document mapping to clusters and reconcile any overlaps.

Diagnostic step 2

For critical VMs, set a static MAC reservation in the VM configuration (edit VM settings -> MAC address -> Manual) and document this as an inventory item. This prevents vCenter from regenerating a MAC. Test on one VM first; the change is reversible by reverting to 'Generated'.

Diagnostic step 3

Collect logs for a reproducer: capture vmware.log from both source and destination hosts around a vMotion, and hostd/vpxd logs from vCenter. Use these when escalating to VMware support if internal audit doesn't reveal the cause.