VMXNET3 interfaces are renamed on migration and take the network down with them

Linux uses predictable network interface names, derived from the device’s position on the PCI bus and the driver that claims it. A VMXNET3 adapter typically appears as ens192 or ens160. Move that VM to a KVM-based platform and the same NIC becomes a VirtIO device on a different bus address, so the kernel names it ens18, enp0s18, or something else entirely.

Nothing has failed at this point. The NIC works, the driver loads, the link comes up. But the configuration that assigns the IP address refers to the old name — /etc/netplan/00-installer-config.yaml, /etc/sysconfig/network-scripts/ifcfg-ens192, or a NetworkManager connection profile bound to an interface name. None of it matches, so none of it applies. The VM boots with a working NIC and no address on it.

The recovery is console access, which is precisely what is scarce during a migration window. A wave of forty Linux VMs that all come up unreachable is a long night, and it is entirely avoidable with a change made before the move rather than after.

The same class of problem hits DHCP reservations. Migration tooling frequently generates a new MAC address rather than preserving the VMware OUI, and any reservation keyed to the old MAC stops matching. The VM gets a pool address instead of its reserved one, and anything referring to it by IP breaks.