VMware ESXi and vSphere Cluster Management

VMware vMotion Requirements and Prerequisites

Learn the VMware vMotion requirements for ESXi hosts, networking, CPU and EVC compatibility, storage, VM networks, licensing, security, and migration validation.

What vMotion Does

vMotion is the live migration of a powered-on virtual machine from one ESXi host to another. The guest operating system and applications continue running, with only a short switchover pause in a normal migration.

vCenter Server initiates and coordinates the migration. It validates the source and destination, selects the migration workflow, coordinates memory and execution-state transfer, and directs the final handoff. During compute vMotion, the VM's memory pages and CPU execution state move to the destination while the VM retains its virtual hardware identity and network configuration.

Do not confuse these migration types:

• Compute-only vMotion: Moves a running VM's execution from one ESXi host to another while its files remain on storage accessible to both hosts.
• Storage vMotion: Moves a running VM's files and virtual disks between datastores while compute remains on the same host unless a combined migration is selected.
• Combined compute-and-storage migration: Moves the running VM to another host and relocates its files, allowing migration without common datastore access when the product version, compatibility, capacity, and network conditions support it.
• Cold migration: Moves a powered-off VM. It does not provide the service continuity of live migration and may be required for unsupported hardware or configuration combinations.

vMotion does not change the guest's IP address. The destination must provide an equivalent logical network so the guest can continue communicating after the handoff.

Core Infrastructure Prerequisites

• The source and destination ESXi hosts should be managed by the same vCenter Server for standard vMotion workflows. Cross-vCenter and long-distance migrations have additional requirements and entitlements.
• Both hosts must use supported and compatible vSphere and ESXi versions, and the destination must support the VM's virtual hardware level and guest operating system.
• The destination host must have enough CPU, memory, and other required resources for the VM, including reservations and resource-pool constraints.
• For compute-only vMotion, both hosts must access every required VM file on the relevant datastore. Shared storage can be VMFS, NFS, vVols, vSAN, or another supported shared datastore type.
• For a migration that also moves storage, the destination datastore must have sufficient free capacity and support the VM's disk format, storage policy, encryption requirements, and virtual hardware configuration.
• The destination must offer the VM's required port group or a compatible distributed port group, with correct VLAN and physical-network reachability.

Host membership in the same cluster is common and simplifies DRS, EVC, resource, and policy management, but cluster membership alone does not make hosts compatible. vCenter's migration compatibility check remains authoritative for the selected workflow.

vMotion Network Requirements

VMkernel adapters and reachability

A VMkernel adapter is an ESXi interface used by host services. Every participating host needs a VMkernel adapter with the vMotion service enabled. Configure its IP address, VLAN-backed port group, subnet or routed path, and intended TCP/IP stack consistently.

The source and destination vMotion VMkernel interfaces require Layer 3 connectivity. They do not have to be in the same IP subnet when routing is correctly configured. Validate:

• VLAN assignment and trunking on virtual and physical switches.
• Routes, gateways, ACLs, and firewalls between the VMkernel addresses.
• MTU consistency across VMkernel adapters, virtual switches, physical switch ports, and every routed hop.
• Correct uplink mapping and physical link speed.
• Low packet loss and sufficient throughput during the migration window.

Bandwidth, uplinks, and multiple adapters

A dedicated physical NIC or uplink capacity for vMotion is preferable to sharing a congested link with management, storage, or high-volume VM traffic. Shared uplinks can work in small environments, but contention increases migration time and may cause failure to converge.

Where supported by the deployed vSphere version and network design, multiple vMotion VMkernel adapters and multi-NIC vMotion can distribute migration traffic across links. Each adapter still requires correct connectivity and consistent policy. A vMotion TCP/IP stack provides separate routing and gateway settings so vMotion traffic can be isolated from management traffic; use it when routing separation or security policy requires an independent path.

MTU and jumbo frames

The standard Ethernet MTU is commonly 1500 bytes. Jumbo frames use a larger MTU, often 9000 bytes, to reduce protocol overhead on a dedicated high-throughput network. Jumbo frames are optional; they are not a substitute for adequate bandwidth or correct routing.

If jumbo frames are selected, configure and verify the complete path: VMkernel interface, standard or distributed switch, physical switch ports, trunks, routers, and any other intermediate device. A single smaller-MTU segment can cause fragmentation, packet loss, or failed migrations. Use an appropriate payload and the do-not-fragment option when testing.

Example network checks

esxcli network ip interface list
esxcli network ip interface tag get -i vmkX
esxcli network nic list
vmkping -I vmkX <destination-vmotion-vmkernel-ip>
vmkping -I vmkX -s 8972 -d <destination-vmotion-vmkernel-ip>

Replace vmkX with the VMkernel interface assigned to vMotion. The first vmkping tests ordinary reachability. The second is an example large-payload test and is appropriate only when the intended end-to-end MTU supports it.

Configure VMkernel service tags, VLAN, MTU, and TCP/IP stack through the vSphere Client, then test between every source and destination host before production migrations.

Virtual Machine and CPU Compatibility

Virtual hardware and guest support

The destination ESXi version must support the VM's virtual hardware compatibility level and guest operating system. Review virtual CPUs, memory, virtual disks, controllers, network adapters, firmware, boot settings, snapshots, and attached devices. A VM can be powered on successfully on one host yet fail migration because the destination cannot provide a required feature.

Running guests also require compatible processor features. The guest may have observed CPU instructions during boot or operation that the destination cannot provide. Hosts from different processor generations, and especially hosts from different CPU vendors, can therefore block live migration.

EVC and per-VM EVC

Enhanced vMotion Compatibility (EVC) establishes a common CPU feature baseline for VMs in a cluster. It hides newer, nonessential CPU instructions so a VM sees a consistent feature set across compatible host generations. Per-VM EVC applies a similar compatibility setting to an individual VM where supported.

Choose an EVC baseline supported by every host that must run the VM. EVC is normally planned before adding newer hosts or mixing processor generations. When EVC is needed, it must be enabled before powering on the VM so the guest receives the intended CPU baseline. A VM that was already running may require a power cycle before the new baseline is presented.

EVC cannot create CPU features that do not exist on the destination, and it does not overcome unsupported platform devices or incompatible firmware capabilities. Read the detailed vCenter pre-check message rather than treating EVC as a universal compatibility solution.

Storage Requirements and Migration Choices

For compute-only vMotion, verify that the destination sees the datastore, has healthy paths, and can access the VM's configuration, virtual disks, logs, snapshots, and swap-related placement. Datastore names should be understandable and consistently presented, although name matching alone does not prove access.

For storage or combined migration, validate destination capacity, provisioning format, storage policy, vSAN policy, vVol backing, encryption, and any snapshot chain. Storage connectivity and policy compliance must be available on the destination host. Raw device mappings and other special storage configurations may impose release-specific restrictions.

VM Network Identity and Port Groups

The destination host must provide the VM's required port group. With a vSphere Standard Switch, recreate compatible port-group and VLAN settings on each host. With a vSphere Distributed Switch, confirm that the destination host is a member and has correct uplinks and VLAN access.

Equivalent network labels are not enough. Two port groups with the same name may have different switch backing, VLAN IDs, security policies, or physical uplink reachability. The VM retains its virtual NIC identity, but the destination must connect that NIC to the same logical network. This is especially important when migrating between racks, clusters, or sites.

Clusters, DRS, HA, and Capacity

Distributed Resource Scheduler (DRS) can place and rebalance VMs automatically using vMotion, or an administrator can initiate a migration manually. DRS still depends on CPU compatibility, storage and network access, destination capacity, and all migration policies.

Check physical capacity and reservations for CPU and memory. Resource pools, VM reservations, expandable reservations, shares, and limits can affect placement. HA admission control reserves capacity for host failures; a destination may appear to have free resources but still be unavailable under the cluster's admission-control policy.

Affinity and anti-affinity rules can restrict target hosts. Review VM-to-host rules, VM affinity, anti-affinity, and DRS automation settings before evacuation. During maintenance mode, vMotion evacuates compatible running VMs; local dependencies and unsupported devices must be remediated or handled separately.

Related configuration topics include DRS automation levels, HA admission control, and ESXi maintenance mode.

Licensing and Feature Availability

Verify the installed vSphere edition, subscription or license entitlement, and deployed version before designing the migration. Entitlement requirements can differ for:

• Standard vMotion.
• Storage vMotion.
• DRS-driven placement.
• Cross-vCenter migration.
• Long-distance vMotion.
• Encrypted vMotion.

Do not assume that every vSphere edition includes every migration feature. Check the licensing interface and the current product compatibility and licensing documentation for the exact release. A feature may also require suitable vCenter configuration, cluster membership, network design, or key-provider support.

Security and Encrypted vMotion

Encrypted vMotion protects migration data in transit, which is valuable when memory contents may contain credentials, application data, or other sensitive information. Where the release provides them, review opportunistic and required encryption modes. Opportunistic mode uses encryption when supported; required mode prevents migration unless the encryption requirement can be satisfied.

Encryption can consume CPU resources and reduce effective throughput, especially on busy hosts or constrained links. Encrypted VMs, key providers, encryption policies, and key availability introduce additional validation requirements. Confirm that source and destination hosts can access the required key-management services and that the selected migration workflow supports the VM's encryption state.

Use network segmentation, restrictive firewall rules, and least-privilege administrative permissions for vMotion. Do not expose vMotion interfaces broadly or treat their traffic as ordinary user traffic.

Pre-Migration Validation Checklist

Run the vCenter migration compatibility check before starting the operation. Read warnings as well as errors: warnings may identify a device, policy, reservation, or performance risk that does not immediately prevent migration. Test with a noncritical VM before maintenance or a large DRS evacuation.

Performance Planning

vMotion first copies VM memory while the guest continues running, then tracks pages changed during the copy. This change rate is called memory dirtying. A workload that modifies memory faster than the network can copy it may take a long time or fail to converge during the final handoff.

Plan for available bandwidth, latency, packet loss, CPU overhead, encryption overhead, and concurrent migration limits. Reduce simultaneous migrations, use dedicated or faster uplinks, and migrate during lower activity periods when a VM has a high dirty-page rate. Large-memory VMs and write-intensive applications need particular attention.

Common Unsupported or Constrained Configurations

Review these items before migration because support depends on the vSphere release and device type:

• PCI passthrough, USB passthrough, physical-device mappings, and other host-bound devices.
• Unsupported virtual devices or special hardware-backed features.
• Host-local dependencies, incompatible firmware capabilities, or differing platform settings.
• Raw device mappings and storage configurations with policy or device restrictions.
• Snapshots, snapshot chains, connected ISO images, mounted physical media, and removable devices.
• Encrypted VMs, key-provider dependencies, and storage or security policies unavailable at the destination.

Disconnect or reconfigure removable media where appropriate, review VM hardware settings, and consult the current support matrix for the exact ESXi release. The migration wizard's detailed validation should be the final authority. If a device cannot be migrated live, plan a cold migration or an application-specific alternative.

Migration Decision Examples

Shared-storage migration in one cluster

Two hosts managed by one vCenter share a VMFS datastore. Each has a vMotion-enabled VMkernel adapter on a routed 10 GbE network, the destination has the VM's distributed port group, and capacity is available. Select compute-only vMotion; the virtual disks remain on the shared datastore.

Different CPU generations

A VM exposes instructions available on a newer source host but not an older destination. Compare the CPU features, select an EVC baseline supported by all participating hosts, and power-cycle affected VMs when required so the baseline is presented. If the required feature cannot be masked, use a compatible destination or a planned outage.

No common datastore

A VM resides on host-local storage and must move to a host with another datastore. Select combined compute-and-storage migration, then validate destination datastore capacity, storage policy, network backing, CPU compatibility, and migration bandwidth.

Jumbo-frame validation

When VMkernel adapters use MTU 9000, verify the virtual switch, physical switches, trunks, and routed path. Run a large-payload vmkping test between the vMotion addresses before production use.

Maintenance evacuation

Before patching an ESXi host, use DRS or manual vMotion to move compatible powered-on VMs to hosts with capacity. Identify VMs with passthrough devices, local storage, affinity restrictions, or other host dependencies before entering maintenance mode.

Common vMotion Compatibility Blockers

vMotion Network Design Options

Related Administration Topics

For supporting skills, review CPU compatibility for vMotion, EVC concepts, distributed switches, VLAN configuration, VMFS datastore access, vSAN datastores, and vCenter-to-ESXi communication.