vSphere vMotion Requirements and Compatibility Checks

Learn the VM, host, shared storage, networking, port group, and CPU compatibility checks required before a traditional vSphere vMotion migration.

vSphere vMotion is the live migration of a powered-on virtual machine from one ESXi host to another with minimal service interruption. The guest continues running while vSphere transfers its active execution state to the destination host.

This lesson focuses on traditional vMotion in which compute moves between hosts while the virtual machine files remain on shared storage. A migration that also moves VMDK files to another datastore is a storage-relocation workflow, commonly called Storage vMotion or a combined compute-and-storage migration, and has additional requirements.

vMotion requirement categories

A migration succeeds only when the destination host can provide every resource the virtual machine needs after the move. Check these categories together:

• Virtual machine requirements: no host-local devices, internal host-only switches, or CPU affinity settings that prevent relocation.
• Host requirements: compatible source and destination ESXi versions, configuration, and available resources.
• Shared-storage requirements: both hosts can access the VM configuration and all required virtual disks and devices.
• vMotion networking: each host has a VMkernel adapter with the vMotion service enabled and reachable by the other host.
• Virtual networking: every port group used by the VM exists and has equivalent network backing on both hosts.
• CPU compatibility: the destination exposes a processor feature set that can safely continue the VM's execution.

Virtual machine device requirements

Inspect the VM hardware before migration. A device that exists only on the source host cannot remain attached when the VM starts on the destination.

Host-local devices and switches

Do not connect the VM to an internal standard switch that exists only on one host. A standard switch is a host-local virtual switch configuration; its port group must be recreated consistently on every eligible destination, or the VM must use a suitable distributed or otherwise available network.

Look for physical or host-specific resources such as:

• A locally attached CD/DVD drive or an image located on source-host storage.
• A floppy drive backed by a source-host resource.
• A serial port connected to a physical device on the source host.
• A host-local disk resource or other device that the destination cannot access.
• An RDM whose backing device is not presented to the destination host.

In the vSphere Client, open the VM hardware settings and identify each device's backing. Disconnect an unnecessary device, remove it, or reconfigure it to use a destination-accessible resource. Run compatibility validation again after changing the hardware.

CPU affinity

CPU affinity pins a virtual machine's virtual CPUs to selected physical CPUs on a host. Those CPU numbers have no portable meaning on another host, so configured affinity can block vMotion. Review the VM's CPU resource settings and remove or redesign affinity before migration unless there is a carefully tested operational reason to retain it.

Virtual machine file accessibility

In shared-storage vMotion, the destination host must be able to open the VM's files while the VM's compute execution moves. Important files include:

• VMX: the virtual machine configuration file describing hardware and settings.
• VMDK: the virtual disk file, including its descriptor and data components where applicable.
• Log files: runtime and diagnostic files used by the VM.
• NVRAM: firmware settings for a VM using virtual firmware such as EFI.

Place these files on a datastore mounted and accessible from both hosts. Shared datastore visibility is necessary because the files remain in place while the VM runs on the new host. Visibility alone is not proof of access: check datastore permissions, backing devices, path health, and the specific files used by the VM.

For an RDM, the destination must have access to the same raw device mapping and the underlying SAN LUN. A VMFS datastore visible to both hosts does not prove that every RDM device is visible to both hosts.

Shared storage requirements

Shared storage is storage that both migration hosts can access concurrently. Traditional shared-storage vMotion commonly uses:

• VMFS: VMware's clustered filesystem for block-storage datastores.
• NFS datastore: a network file system datastore mounted by ESXi hosts.

Compare the datastore inventory on the source and destination. Confirm that every datastore containing the VMX, VMDK, log, NVRAM, snapshot, and relevant device files is mounted on both hosts. For block storage, verify that the destination has the required LUN presentation and healthy paths. For NFS, verify the export, network access, and mount configuration. A local datastore available only to the source cannot support classic shared-storage vMotion; relocate the files first or use a migration method that supports storage relocation.

vMotion VMkernel networking

A VMkernel adapter is an ESXi host network interface used for services such as management, storage, and vMotion. Each participating host needs a VMkernel adapter with the vMotion service enabled. The two vMotion VMkernel interfaces must be able to communicate across the designed network.

Use at least Gigabit Ethernet as the baseline. A dedicated or sufficiently provisioned faster link generally shortens migration time and reduces contention. vMotion traffic is host-to-host migration traffic; it is different from the guest network traffic carried by the VM's virtual NICs.

Validate the complete path:

• Confirm the IP address, subnet, and VMkernel service tag on both adapters.
• Check VLAN IDs, physical switch trunks, permitted VLANs, uplinks, and any required routing.
• Keep MTU settings consistent end to end. Jumbo frames are useful only when every hop supports the selected MTU.
• Test VMkernel-to-VMkernel reachability, not merely management-address reachability.

esxcli network ip interface list
esxcli network ip interface tag get
vmkping <destination-vmotion-vmkernel-ip>
vmkping -d -s <payload-size> <destination-vmotion-vmkernel-ip>

The second vmkping form tests a selected payload without fragmentation and is useful when validating jumbo-frame paths. Select a payload appropriate for the intended MTU.

Virtual machine port group consistency

Every virtual NIC configured on the VM must have a valid destination network. This includes adapters that are currently disconnected but remain configured: the port group assignment can still be evaluated during migration.

On both hosts, verify that each required port group:

• Exists on the host.
• Has the exact expected name. Standard-switch port group names are case-sensitive.
• Connects to the same intended VLAN and physical network.
• Has working uplinks and equivalent reachability for the guest workload.

A missing port group can prevent the migration or leave the VM without the intended network connection. A name that matches but has different VLAN backing can silently place the guest on the wrong network. Inventory all vNICs, not only the primary production adapter.

esxcli network vswitch standard portgroup list

CPU compatibility

The source and destination processors must expose a compatible feature set so the running VM can continue on the destination. The historical baseline is matching CPU vendor, a compatible processor family, and all required CPU features.

Intel-to-AMD and AMD-to-Intel vMotion migrations are not supported by this compatibility model. Even hosts from the same vendor can differ by generation or BIOS-exposed feature. Two hosts that appear similar by model name can therefore fail validation.

CPU compatibility masks

A CPU compatibility mask hides selected processor features from a VM. This can establish compatibility with an older processor feature set, but masking must be planned and tested. Hiding a feature can affect application behavior or guest performance, and arbitrary masking is not a substitute for a supported design.

Enhanced vMotion Compatibility

Enhanced vMotion Compatibility (EVC) is a cluster-level capability that presents a common CPU feature baseline to VMs where supported. Establish an appropriate EVC baseline before relying on migration, automated placement, or host maintenance evacuation across different CPU generations. CPU compatibility must be assessed before those operations, not after a workload has been placed on an incompatible host.

Pre-migration validation workflow

1. Confirm shared datastore access. Compare mounts and verify access to every file used by the VM.
2. Inspect VM devices. Find internal standard-switch dependencies, physical CD/DVD, floppy, serial, host-local disk, and other host-specific resources.
3. Review CPU affinity. Remove settings that pin the VM to physical CPUs on the source.
4. Validate RDM visibility. If present, confirm the destination can see the mapping, backing LUN, and healthy storage paths.
5. Validate every VM port group. Compare all vNIC assignments, exact names, VLANs, uplinks, and network intent.
6. Validate vMotion networking. Confirm the VMkernel service, addressing, VLAN reachability, routing where needed, and MTU.
7. Review CPU compatibility. Check vendor, family, exposed features, EVC, and any compatibility mask.
8. Run vCenter validation. Use the migration wizard's compatibility check and resolve every blocker before starting the move.

When introducing a new vMotion network or a new host combination, test with a noncritical VM first. A successful ping alone does not prove that the vMotion service, VLAN, MTU, storage paths, port groups, and CPU baseline are correct.

vMotion requirement checklist

Virtual machine resources that can prevent vMotion

Network validation matrix

Migration failure interpretation

Command-line and vSphere Client checks

In the vSphere Client, verify VMkernel service assignment, inspect VM hardware, review CPU affinity, compare port groups and VLAN backing, review datastore mounts and device visibility, and use the migration workflow's compatibility validation.

On ESXi, these examples support investigation:

esxcli storage filesystem list
esxcli storage core path list
esxcli network vswitch standard portgroup list

Use esxcli storage filesystem list to compare mounted datastores. Use esxcli storage core path list to review SAN paths, especially for RDM-backed workloads. Use the standard-switch port group command to compare host-local network definitions.

Practical scenarios

Missing destination port group

A VM has production and backup vNICs, but the destination has only the production port group. Inventory both vNIC assignments, create or correctly map the backup network on the destination, and verify exact case-sensitive names, VLAN IDs, uplinks, and network equivalence before retrying.

Host-local CD/DVD device

A connected CD/DVD drive uses a physical device on the source. Identify it as host-specific, disconnect it or select a destination-accessible backing, then rerun compatibility validation.

RDM visible only on the source

A database VM uses an RDM backed by a SAN LUN that is not presented to the destination. Confirm LUN presentation, device discovery, path health, and mapping access on the destination. Do not infer RDM access from shared VMFS visibility.

CPU mismatch

A VM runs on an older Intel host and is targeted to a newer Intel host with different exposed features. Use compatibility validation to identify the feature difference, then evaluate a supported common EVC baseline. A move between Intel and AMD is not solved by ordinary cluster configuration.

Unreachable vMotion VMkernel interfaces

Both hosts have vMotion-marked VMkernel adapters, but they are on isolated VLANs. Check IP addressing, VLAN assignment, physical uplinks, permitted trunks, routing where applicable, and MTU. Test the VMkernel addresses directly and confirm the adapters are enabled for vMotion.

VM files on local storage

If the VM's files are on a datastore available only to the source, classic shared-storage vMotion cannot leave those files behind. Move the files to shared storage first or choose a supported migration method that includes storage relocation.

Use this vMotion requirements checklist as a pre-flight review before host maintenance, automated placement, or a manual live migration.