Understanding vSphere vMotion and Its Compatibility Constraints

vSphere vMotion moves a running virtual machine from one ESXi host to another with little or no noticeable interruption. It is a core capability for maintenance, load balancing, hardware refreshes and automated cluster operations. When configured correctly, an administrator can evacuate a host, patch it and return it to service without scheduling a lengthy outage.

The process is more demanding than selecting a destination host in vCenter Server. vMotion must preserve the virtual machine’s CPU execution state, memory contents, virtual networking and storage access. Any mismatch in the source and destination environment can prevent the migration or create an operational risk.

This matters in Australian environments where workloads may span a Sydney data centre, a Melbourne disaster recovery site, a Brisbane office and smaller regional facilities. WAN latency, bandwidth costs and data residency requirements can make a cross-site migration very different from a move inside one rack.

For background on the author’s infrastructure experience and technical focus, see Jonathan’s background. The same practical approach applies here: validate the platform, test the failure cases and treat compatibility as a design requirement rather than a last-minute checkbox.

What Happens During A vMotion

vMotion begins by reserving resources on the destination ESXi host and establishing a migration connection between the two hosts. The source host copies the virtual machine’s memory pages while the workload continues running. Pages changed during the first copy are sent again in successive rounds.

When the remaining changed pages can be transferred quickly enough, vSphere briefly quiesces the virtual machine, copies its final CPU and memory state, and starts it on the destination. The VM’s identity, virtual hardware and network configuration remain intact, so users generally see only a very short pause.

The migration network carries memory and execution-state traffic, which can be substantial for a busy VM. A dedicated VMkernel adapter, correctly configured MTU settings and sufficient uplink capacity help prevent vMotion from competing with management, vSAN or production traffic.

CPU Compatibility And EVC

The most familiar constraint is processor compatibility. Intel and AMD hosts cannot generally participate in the same live vMotion operation because their CPU instruction sets differ. Even within one vendor, newer processors may expose instruction sets that older CPUs cannot provide.

Enhanced vMotion Compatibility, or EVC, establishes a common baseline for a cluster. It masks selected newer CPU features from virtual machines, allowing hosts from different processor generations to present a consistent virtual CPU. EVC does not turn incompatible hardware into identical hardware, and it does not remove every limitation.

EVC is easiest to enable before workloads are placed in a cluster. Existing virtual machines may need to be powered off, rebooted or otherwise assessed when changing the baseline. A careful upgrade plan is particularly important in Australian colocation facilities, where after-hours access in Perth or Darwin can be expensive and local hands may need to be booked well ahead.

Networking And Storage Requirements

Both ESXi hosts need equivalent access to the virtual machine’s networks. The destination must have the required port group or distributed switch configuration, VLAN reachability and suitable uplinks. A VM can migrate successfully at the compute layer yet lose connectivity if its destination port group is missing or mapped incorrectly.

Storage visibility is another major consideration. Traditional vMotion expects the source and destination hosts to access the VM’s files through shared storage such as Fibre Channel, NFS or iSCSI. vSAN supplies a shared datastore model within its cluster, while vSphere also supports shared-nothing migration in suitable editions and configurations.

Storage policy, datastore accessibility and virtual hardware settings should be checked before migration. A VM connected to a datastore visible only from the source host cannot be moved using ordinary compute vMotion. Cross-datastore or combined compute-and-storage migration consumes additional bandwidth, which may be significant across a constrained link between Sydney and a regional site.

Version, Configuration And Security Checks

ESXi and vCenter Server versions must support the intended migration path. VMware generally supports vMotion between compatible releases, but feature availability can vary with the direction of migration and the hardware version of the VM. Keeping hosts within a supported upgrade sequence avoids surprises during a maintenance window.

Virtual machines with snapshots, independent disks, passthrough devices, USB connections or specialised virtual hardware need extra attention. PCI passthrough and some device assignments tie a VM to particular host hardware. A VM using an incompatible device may need to be powered down before it can move.

Encrypted vMotion adds another layer of policy and configuration. Hosts must support the required encryption features, and security settings must align across the cluster. Organisations handling government, healthcare or financial workloads in Australia should also document how migration traffic is protected and where it travels, especially when a platform touches public cloud or an overseas facility.

Planning Reliable Migration Operations

Start with a compatibility matrix covering CPU generation, EVC mode, ESXi build, VM hardware version, port groups, datastore access and special devices. vCenter compatibility checks are useful, but they should be treated as one source of evidence rather than a substitute for design documentation.

Test representative workloads before relying on automated DRS placement. Include high-memory VMs, latency-sensitive applications, database servers and systems with large active memory footprints. Monitor vMotion duration, packet loss, CPU ready time and application response during the test.

Free operational resources such as virtualisation tools can complement built-in vSphere checks when documenting hosts, PowerCLI workflows and repeatable administration tasks. Automation is especially valuable for larger Australian organisations managing several clusters across Sydney, Melbourne and Brisbane, where manual validation can drift between sites.

For a home lab, nested ESXi or a small cluster is an effective way to observe these constraints without risking production. For enterprise platforms, schedule migrations around application dependencies, confirm rollback options and record the reason a VM was excluded from DRS or vMotion.

Use the Virtxpert technology blog as a practical reference while building checklists, PowerCLI routines and troubleshooting notes. Then validate each migration path against the versions and hardware actually deployed in your environment.

Run a controlled vMotion test, capture the compatibility results and turn the findings into a repeatable change procedure before your next host maintenance window.