VMware ESXi and vSphere Cluster Management
CPU Compatibility Requirements for VMware vSphere vMotion
Learn how CPU vendors, instruction sets, EVC, CPU masking, NX/XD, and vCenter checks affect live VMware vSphere vMotion migrations.
vSphere vMotion moves a running virtual machine from one ESXi host to another without a planned shutdown of the guest operating system. CPU compatibility is the condition that allows the guest to continue executing instructions during that move.
This lesson explains the CPU checks behind vMotion, how to validate them, and how to plan mixed-generation host upgrades. CPU compatibility is only one part of a migration: networking, storage, VM configuration, licensing, and other vMotion prerequisites must also be valid.
Why CPU compatibility matters during vMotion
An ESXi host is the hypervisor server that runs virtual machines. The guest operating system runs inside the VM and sees a virtual processor presented by ESXi.
When a VM boots, its guest operating system and applications inspect processor capabilities. This inspection commonly uses CPUID, the processor identification and feature-reporting mechanism. The guest may then select code paths that use available instruction sets or hardware functions.
During vMotion, the VM remains powered on. Its memory and execution state are transferred while the guest continues running. The destination therefore must be able to provide a processor feature set compatible with the one already visible to the VM. If the VM could use an instruction on the source but the destination cannot provide it, the migration may be rejected. In unsuitable circumstances, forcing an incompatible presentation can cause guest instability or application failures.
Core CPU compatibility requirements
Same processor vendor
Normal CPU compatibility mechanisms generally require the source and destination hosts to use processors from the same vendor, such as Intel-to-Intel or AMD-to-AMD. Intel and AMD implement different processor architectures and expose different combinations of feature bits. A running VM cannot ordinarily be live-migrated directly between the vendors through standard CPU compatibility settings.
Compatible family and processor generations
A CPU family is a processor lineage that indicates a broad architecture and instruction-set level. Hosts do not necessarily need identical models, but their processor generations and families must support a common feature baseline suitable for the VM.
A newer processor may support capabilities that an older processor lacks. If those capabilities are exposed to a VM and the VM starts using them, the VM may no longer be movable to the older host. The reverse direction can be possible when the newer host supports the older host's exposed feature set.
Compatible instructions and hardware features
A CPU feature bit is a capability flag reported by a processor. Feature bits can describe instruction sets, security functions, acceleration facilities, and other hardware behavior. The destination must be able to preserve the feature set visible to the guest, either naturally or through a supported compatibility baseline.
Common feature categories include:
- SSE-family instructions: SIMD instructions used by many operating systems and applications.
- AVX-family instructions: newer vector-processing capabilities that may be absent on older processors.
- AES acceleration: hardware support that can improve encryption workloads.
- Virtualization extensions: processor capabilities used for virtualization-related functions, where exposed and supported by the relevant configuration.
- Generation-specific capabilities: additional instruction sets, security features, or performance functions introduced by later processor families.
A feature available only on the source can block vMotion if it is part of the VM's visible CPU presentation. Matching clock speed, core count, or cache size is not the central vMotion CPU compatibility test. Those properties affect capacity and performance planning, but feature continuity is the primary live-migration concern.
CPU feature exposure to virtual machines
ESXi takes capabilities from the physical host and presents a virtual CPU to the VM. The resulting presentation is not necessarily an unrestricted copy of every host feature. It is a defined set of CPU feature bits and instructions that the guest can detect.
The VM can safely migrate only when the destination can provide the same visible set, or when the migration is controlled by a compatible common baseline. A feature that exists physically on a source host is not automatically harmless: if ESXi exposes it and the guest uses it, the destination must support it too.
Consider a VM booted on a newer Intel host. The host and VM configuration expose an AVX-family feature that is missing from an older Intel host. The VM may boot successfully on the newer host, but a reverse live migration can fail because the older destination cannot maintain the VM's CPU contract.
NX and XD consistency
The NX bit, or No-Execute capability, is a processor memory-protection feature. It allows memory pages to be marked as non-executable, helping prevent code execution from regions intended only for data. XD, or Execute Disable, is Intel's name for an equivalent-purpose capability.
NX/XD presentation must be consistent for vMotion compatibility. If the source exposes the capability and the destination does not, or if host firmware settings result in different presentations, vCenter can report a CPU compatibility problem.
Administrators may need to expose or hide NX/XD consistently across participating hosts, depending on the required baseline and vSphere configuration. This is not a cosmetic change. Altering execute protection can affect guest operating-system behavior, security controls, and application compatibility. Check the guest requirements and security policy before changing BIOS, firmware, or VM CPU settings. Revalidate the migration after making the change.
CPU compatibility mitigation options
CPU masking
CPU masking hides selected processor capabilities from a VM. By concealing newer or otherwise unsuitable feature bits, an administrator can establish a common feature baseline that multiple hosts support.
Masking is a trade-off. The guest cannot use a feature that has been hidden, even when the physical host supports it. This may reduce application performance or prevent software from using an acceleration feature. Masks should therefore be narrowly scoped, documented, and validated for the specific vSphere release and processor combination.
A changed CPU presentation generally must be in place before the VM boots, or the VM must be rebooted or power-cycled for the guest to detect the new presentation. A live guest does not normally rediscover its complete processor identity safely during ordinary operation.
Enhanced vMotion Compatibility
Enhanced vMotion Compatibility (EVC) is a vSphere cluster feature that standardizes the CPU feature baseline presented to VMs across compatible hosts. It is usually preferred over manual per-VM masks when a whole cluster must support mixed processor generations.
Choose an EVC mode supported by every host that must participate in the cluster. During a hardware refresh, the oldest required host generation commonly determines the baseline. Newer hosts can then join the cluster while VMs receive a feature set that remains usable on both generations.
EVC and manual masking are different:
- EVC: cluster-level policy that provides a common baseline across compatible hosts.
- Per-VM masking: an individual VM configuration used for a narrowly scoped compatibility requirement.
Confirm the effect of EVC on existing powered-on VMs. A reboot may be necessary before a VM receives the selected baseline, especially when it was previously booted with a broader feature set.
Cold migration or shutdown and restart
A powered-off VM has no running CPU state to preserve. It can often boot on a different compatible or newer CPU baseline after startup, subject to the VM's configuration and general vSphere requirements. This is less restrictive than moving a running VM, but it is not a way to make cross-vendor live migration supported.
Validation and migration planning
- Inventory the hosts. Record processor vendor, family, model, stepping, firmware level, and relevant feature differences.
- Determine the target baseline. Identify the oldest host that must continue receiving workloads and choose a supported common feature level.
- Check cluster EVC. Confirm whether EVC is enabled and whether its mode is supported by every participating host.
- Review VM-specific settings. Look for custom CPU masks, virtual CPU configuration, and VMs that were booted before the intended baseline was established.
- Run the vCenter compatibility check. Use the built-in migration validation before initiating vMotion. Record the exact missing or mismatched CPU feature.
- Separate CPU blockers from other blockers. Review network, datastore, device, licensing, and VM-configuration warnings independently.
- Test representative workloads. Perform test migrations for different guest operating systems and application types, including CPU-intensive and security-sensitive workloads.
- Refresh hosts in a safe sequence. Establish the common baseline, migrate or power-cycle affected VMs when required, then retire old hosts after the environment has been revalidated.
Safe mixed-generation refresh example
Suppose a cluster contains older and newer processors from the same vendor. First select an EVC baseline supported by the older hosts. Add or prepare the newer hosts, verify that all hosts support the selected mode, and confirm the cluster's compatibility checks. Reboot VMs that need to acquire the standardized presentation during an approved maintenance window. Once representative migrations work in both directions, workloads can move while both generations remain in service.
vMotion CPU Compatibility Checklist
| Validation item | What must match or be compatible | Why it matters | Typical validation method |
|---|---|---|---|
| CPU vendor | Same vendor, such as Intel-to-Intel or AMD-to-AMD | Different vendors expose incompatible processor architectures and feature sets | Compare host hardware inventory in vCenter |
| CPU family and supported baseline | A common family or supported EVC baseline | The destination must preserve the running VM's processor contract | Review host details and cluster EVC support |
| Exposed instruction-set features | All features visible to the VM must be available at the destination or covered by a baseline | Source-only instructions can prevent live migration | Read the detailed vCenter compatibility message |
| EVC mode | A mode supported by every participating host | Standardizes the CPU feature presentation across generations | Inspect cluster EVC configuration |
| Per-VM CPU masks | Custom masks must not conflict with the target hosts or EVC policy | Manual settings can hide features or create unsupported combinations | Review VM CPU configuration and change records |
| NX/XD presentation | Consistent exposure across hosts and VM settings | Inconsistent execute-protection capability can block vMotion | Compare BIOS or firmware settings and vCenter messages |
| Guest reboot status after baseline changes | VM must be rebooted when required to detect the new presentation | A running guest may retain the CPU capabilities selected at boot | Check VM uptime and maintenance records |
Compatibility Strategy Comparison
| Strategy | Scope | Best use case | Advantages | Limitations |
|---|---|---|---|---|
| No masking with matching CPUs | Hosts with naturally compatible features | Uniform hardware generations and a stable cluster | Preserves available CPU functionality and is simple to operate | Can fail when newer and older generations are mixed |
| Cluster EVC | Cluster-wide | Mixed compatible generations from the same vendor | Centralized, repeatable baseline for many VMs | Baseline may withhold newer features; supported mode and reboot requirements apply |
| Per-VM CPU masking | Individual VM | Narrow compatibility exception | Targets only the workload that needs adjustment | Operationally complex, may reduce functionality, and requires careful supportability review |
| Cold migration or shutdown and restart | Individual migration event | Live compatibility cannot be established | Removes the need to preserve a running CPU state during transfer | Requires downtime and still depends on successful boot and general VM compatibility |
Common vMotion CPU Mismatch Outcomes
| Mismatch type | Expected result | Recommended response |
|---|---|---|
| Different CPU vendors | Normal CPU compatibility mechanisms do not permit direct live migration | Migrate within same-vendor hosts or shut down and restart on the target after validating the VM |
| New instruction set on source only | vMotion is blocked because the destination cannot preserve a visible feature | Use a suitable EVC baseline, a validated mask, or a powered-off move |
| EVC baseline not enabled or too new | Older hosts cannot accept VMs using features above their capability | Select a baseline supported by every required host and reboot affected VMs |
| NX/XD exposure mismatch | Compatibility check reports an execute-protection difference | Align host presentation after assessing guest security and operating-system effects |
| Custom CPU mask conflict | VM configuration or target host cannot satisfy the requested feature presentation | Review, document, and revise the mask using release-specific guidance |
Troubleshooting CPU compatibility errors
vMotion fails with a CPU compatibility error
Likely causes include different CPU vendors, a destination that lacks a feature exposed on the source, or an unsuitable or missing EVC baseline.
- Compare source and destination processor vendor and family.
- Read the detailed vCenter migration compatibility message rather than relying only on the summary.
- Check the cluster EVC mode and host support.
- Review custom per-VM CPU masks and recent VM configuration changes.
- Choose compatible same-vendor hosts, configure a supported EVC baseline, apply a validated mask with any required reboot, or shut down and restart the VM on the target.
Older and newer same-vendor hosts cannot migrate in both directions
The VM may have been booted on the newer host and exposed to features unavailable on the older host. EVC may also have been enabled only after the VM started.
Identify the newer-only features, verify the intended EVC mode, and reboot affected VMs so they start with the standardized presentation. Until then, keep them on hosts that support their current feature set.
Migration is blocked by NX/XD messaging
Compare NX/XD settings and feature reporting on both hosts. Check guest operating-system requirements before changing firmware settings. Align the presentation, reboot VMs when required, and rerun the compatibility check. If the hosts cannot be standardized, use another compatible target or a planned shutdown.
Operational limitations and expectations
- CPU compatibility does not satisfy all vMotion prerequisites. Management and vMotion networking, storage accessibility, VM devices, licensing, permissions, and cluster configuration must also be checked.
- Cross-vendor live migration is generally not supported through normal CPU compatibility mechanisms.
- A powered-off VM can boot with a different compatible or newer CPU baseline, but the guest and applications must still support that environment.
- Unsupported manual masks or unsuitable EVC baselines can affect VMware supportability and workload performance.
- Hiding a CPU feature can make a migration possible while preventing the guest from using an instruction set or acceleration function that would otherwise improve performance.
- Clock frequency, core count, and cache size remain important for capacity and performance planning, but they are not the primary feature-continuity test for vMotion.
Exam-relevant notes
- vMotion moves a powered-on VM, so the destination must preserve the CPU capabilities already visible to the guest.
- Same CPU vendor is a fundamental requirement for ordinary CPU compatibility mechanisms.
- EVC provides a cluster-level common CPU baseline; CPU masking is generally a per-VM adjustment.
- NX and XD are names for equivalent execute-protection capabilities and must be presented consistently.
- Changing the visible CPU feature set commonly requires the VM to boot or reboot before the guest detects it.
- Different clock speeds or cache sizes alone do not determine vMotion CPU compatibility.
For related planning, use this CPU compatibility for vMotion reference alongside your vCenter compatibility checks and host-refresh runbook.