CPU Compatibility Requirements for vSphere vMotion
Learn how CPU vendors, generations, feature flags, EVC, CPU masking, and NX/XD settings affect vSphere vMotion compatibility.
CPU compatibility is a fundamental requirement for vSphere vMotion, which is the live migration of a powered-on virtual machine from one ESXi host to another. Unlike a cold migration, vMotion moves the VM while its guest operating system continues running.
This article explains how ESXi presents a virtual CPU (vCPU) to a guest, why source and destination hosts must provide compatible capabilities, and how Enhanced vMotion Compatibility (EVC), CPU masking, and NX/XD settings affect migration decisions.
Contents
- Why vMotion requires CPU compatibility
- Core source and destination requirements
- CPU families and feature flags
- CPU masking and EVC
- NX/XD execution protection
- Planning and validation
- Interpreting common incompatible scenarios
- Troubleshooting checklist
Why vMotion Requires CPU Compatibility
An ESXi host is a VMware hypervisor server that supplies physical CPU resources to virtual machines. The guest does not normally use the physical processor directly. Instead, ESXi presents a virtual processor interface containing a selected set of CPU capabilities.
When a VM powers on, its guest operating system detects the vCPU capabilities presented by ESXi. The guest may then enable instruction extensions, operating-system optimizations, cryptographic operations, memory-protection behavior, or application features based on those capabilities.
During vMotion, the guest operating system is not restarted. Its execution state, memory, and active virtual hardware are transferred to the destination host. Therefore, the destination must continue to provide the CPU instructions and feature flags that were visible to the VM when it booted.
If the destination lacks a feature that the running guest expects, the guest could attempt to execute an unavailable instruction or use an unavailable platform capability. To prevent that unsafe condition, vSphere performs CPU compatibility checks before allowing the migration.
Core Source and Destination CPU Requirements
CPU compatibility means that the destination host can provide the virtual CPU vendor, family baseline, and feature set required by the running VM. The main requirements are:
- Same CPU vendor: The source and destination must use processors from the same vendor, such as Intel-to-Intel or AMD-to-AMD. Live migration between Intel and AMD is not supported by vMotion.
- Compatible CPU family and generation: The processors must share a compatible architectural baseline, either naturally through similar hardware or through an appropriate EVC baseline.
- Destination feature availability: Every CPU feature exposed to the powered-on VM on the source must also be available on the destination.
- Consistent execution-protection behavior: NX/XD presentation must be compatible with the VM's existing virtual CPU state.
Matching clock speed, physical core count, or the exact processor model is not the primary vMotion CPU test. Those characteristics affect performance and capacity, but vMotion compatibility focuses mainly on the instruction-set capabilities and feature flags exposed to the virtual machine.
Vendor, family, and feature flag definitions
- CPU vendor is the processor manufacturer identity, such as Intel or AMD.
- CPU family is a processor architectural lineage with a related feature set and instruction behavior.
- CPU feature flags are advertised processor capabilities or instruction-set extensions visible to software.
- Virtual CPU is the processor interface that ESXi presents to the guest operating system.
CPU Family and Feature Compatibility
A newer processor generation can support all, or nearly all, capabilities of an older generation while adding new instructions and feature flags. This does not automatically make every migration direction safe.
For example, suppose a VM starts on a newer Intel host and ESXi exposes a feature that is absent on an older Intel host. The VM may enable that feature during boot. A later vMotion attempt from the newer host to the older host can be blocked because the destination cannot reproduce the VM's current CPU presentation.
The reverse direction may succeed: an older-generation VM may use only features available on the newer host. Compatibility must therefore be evaluated in the direction of migration and against the feature set currently visible to the VM.
Two hosts can also have similar product branding while exposing different feature flags. Differences may result from processor stepping, firmware, BIOS or UEFI configuration, ESXi configuration, or the selected virtual CPU policy. Hardware labels alone are not sufficient evidence of compatibility.
CPU Masking as a Compatibility Mitigation
CPU masking restricts selected CPU features presented by an ESXi host to a virtual machine. A mask can hide newer or incompatible features so the VM sees a smaller common baseline that is available on several hosts.
For example, a VM running on a newer processor may be configured not to see a feature that an older same-vendor host lacks. If the VM boots with that reduced presentation, it may then be able to move among hosts that support the selected baseline.
The trade-off is important: a masked feature is unavailable to the guest even when the physical processor supports it. Applications and guest operating systems cannot use hidden instructions or extensions. Masking can also affect performance or application compatibility if the removed feature was useful.
Use per-VM masking as a targeted, documented compatibility method. It is not a substitute for compatible cluster hardware, and it should be validated with the guest operating system and workload before production use.
Enhanced vMotion Compatibility (EVC)
Enhanced vMotion Compatibility (EVC) is the cluster-level mechanism for presenting a consistent CPU baseline to VMs across compatible host generations. EVC masks newer CPU features so that VMs use a feature set supported by all hosts participating in vMotion.
In a mixed-generation cluster, the EVC baseline is normally selected from the oldest supported host generation. Newer hosts can still provide their physical CPU resources, but features above the selected baseline are hidden from VMs in that EVC domain.
- Intel and AMD have separate EVC modes and baselines.
- EVC does not translate Intel instructions into AMD instructions or AMD instructions into Intel instructions.
- All hosts intended to participate in the cluster must support the selected EVC baseline.
- A baseline reduces the guest-visible feature set, so workloads cannot use features hidden by EVC.
Plan EVC before powering on workloads in a heterogeneous cluster. Existing powered-on VMs may already have a newer feature set exposed. Enabling or changing EVC does not necessarily retroactively alter the CPU state with which those VMs booted. Schedule required power cycles and verify the supported workflow for the vSphere version in use.
For broader cluster preparation, see Create Clusters and VMware ESXi Online Course.
NX and XD Bit Handling
The NX bit is AMD terminology for a no-execute memory-protection capability. The corresponding Intel term is the XD bit, meaning execute disable. Both refer to hardware support that helps prevent code from executing in memory regions intended only for data.
ESXi can expose or hide this execution-protection capability as part of the VM's virtual CPU configuration. The presentation must remain compatible during vMotion. If a guest booted with NX/XD visible, the destination must provide the corresponding capability. If the guest booted with it hidden, changing the presentation during a live migration can also create an incompatible virtual CPU state.
NX/XD has two important implications:
- Guest operating system behavior: The operating system may select memory-protection policies and kernel behavior based on whether the capability is available.
- Security: Hiding execution protection can weaken defenses against certain classes of memory-execution attacks. Do not change the setting merely to bypass a compatibility warning without assessing the guest and security requirements.
Check host firmware and vSphere settings when a migration reports an NX/XD mismatch. Align the capability across the migration hosts, or plan a shutdown if the VM's virtual CPU presentation must change.
vMotion CPU Compatibility Checklist
| Compatibility area | Requirement | Why it matters | Typical remediation |
|---|---|---|---|
| CPU vendor | Source and destination use the same vendor. | Intel and AMD have different architectural feature sets and are not interchangeable for live migration. | Choose a same-vendor destination or use a planned cold migration for a platform move. |
| CPU family or EVC baseline | Both hosts support a common family or selected EVC baseline. | The VM must retain a compatible architectural baseline after migration. | Select an EVC baseline supported by every participating host. |
| CPU feature flags | The destination provides every feature currently exposed to the VM. | The running guest may already depend on those instructions or capabilities. | Use a compatible host, establish EVC before boot, or apply a validated feature mask. |
| NX/XD bit exposure | Execution-protection presentation is consistent. | The guest may have configured itself based on the capability being visible or hidden. | Align firmware and virtual CPU settings, or power off before changing them. |
| Existing powered-on VM CPU state | Account for the feature set with which the VM actually booted. | Changing cluster policy does not always change the state already selected by a running guest. | Schedule a power cycle under the intended baseline or keep the VM on suitable hosts. |
Migration Scenario Outcomes
| Source host | Destination host | VM CPU presentation | Expected vMotion result | Recommended action |
|---|---|---|---|---|
| Intel | Intel, common EVC baseline | Only features in the shared baseline are exposed. | Normally compatible if all other vMotion requirements pass. | Use the common EVC baseline and validate the cluster. |
| Newer Intel generation | Older Intel generation without EVC | The VM sees a newer feature absent from the destination. | Blocked when the feature is required by the running VM. | Use EVC planned before boot, a validated mask, or cold migration. |
| Older Intel generation | Newer Intel generation | The VM uses an older-compatible feature set. | Often compatible, subject to all exposed features and configuration. | Run the vSphere compatibility check before migration. |
| AMD | Intel | Vendor and architectural feature sets differ. | Unsupported for live vMotion. | Use a workload migration strategy that includes a shutdown and platform conversion planning. |
| NX/XD visible or hidden | Different NX/XD presentation | The running VM's execution-protection state differs from the destination. | May be blocked as an NX/XD compatibility mismatch. | Align exposure or schedule a power-off and reboot. |
Compatibility Approaches Compared
| Approach | Scope | Effect on guest-visible CPU features | When to use | Key limitation |
|---|---|---|---|---|
| Consistent host hardware | Cluster or migration domain | Preserves a broadly similar physical feature set. | When designing new clusters or standardizing hardware. | Hardware refreshes can reintroduce generation differences. |
| Cluster EVC | All eligible VMs in a cluster or EVC domain | Hides features above the selected common baseline. | For mixed-generation, same-vendor clusters. | Every host must support the baseline, and newer features are unavailable to guests. |
| Per-VM CPU masking | One virtual machine | Hides specifically selected features from that VM. | For a documented workload-specific compatibility exception. | Requires careful testing and can reduce guest capabilities. |
| Cold migration and reboot | Individual VM move | The guest detects the destination presentation at its next boot. | When live compatibility is impossible and downtime is acceptable. | Requires an outage and may expose a materially different CPU environment. |
Planning and Validation Before Migration
- Inventory every prospective host. Record CPU vendor, family, generation, firmware level, and relevant exposed feature differences.
- Define the migration domain. Identify which hosts must accept the same powered-on VMs and whether they belong to one cluster or EVC domain.
- Choose the baseline early. If host generations differ, establish an EVC mode supported by every participating host before powering on new workloads.
- Review existing VMs. Determine which VMs were powered on before EVC planning and what CPU features they currently see.
- Validate the destination in vSphere. Use the vSphere Client migration workflow and its compatibility checks before attempting a production vMotion.
- Test representative workloads. Include older operating systems and applications that depend on specific CPU extensions or execution-protection behavior.
- Document exceptions. Record VMs that require a shutdown, a particular destination host, or a specific CPU mask.
CPU compatibility is only one part of a successful migration. Also verify vMotion networking, storage access, permissions, and cluster placement requirements. For host inventory operations, see Add ESXi Host to vCenter Server Inventory.
Interpreting Incompatible vMotion Scenarios
Intel-to-AMD or AMD-to-Intel
Cross-vendor live migration is unsupported because the processor vendors use fundamentally different instruction-set and architectural feature models. CPU masking does not convert one vendor's virtual CPU into the other's.
Newer generation to older generation
This direction commonly fails when the VM was powered on while newer features were exposed. The older destination may lack one or more features currently required by the VM. A common EVC baseline must be selected before the VM boots, or the VM must be power-cycled under a compatible presentation.
Similar branding but different flags
Hosts that appear to have similar processor names can still differ in firmware-exposed capabilities, processor stepping, BIOS configuration, or ESXi feature handling. Compare actual compatibility results and feature differences rather than relying only on model branding.
NX/XD mismatch
If the source VM booted with execution protection visible and the destination cannot expose it, or if the presentation is otherwise inconsistent, vMotion can be blocked. Check firmware, host settings, VM CPU configuration, and guest requirements before changing the setting.
Cold migration as an alternative
A cold migration occurs while the VM is powered off. After the VM is moved and booted on the destination, the guest detects the destination's virtual CPU presentation anew. This can change the compatibility situation, but it does not remove the need to plan for guest behavior, vendor differences, application support, and downtime.
Troubleshooting vMotion CPU Failures
Symptom: The compatibility check reports incompatible CPU features
- Confirm that source and destination hosts use the same CPU vendor.
- Compare CPU generation, family, firmware, and exposed feature differences.
- Determine which feature is currently visible to the powered-on VM.
- Check whether a suitable EVC mode is enabled and supported by all hosts.
- Assess whether the workload can use a lower baseline or requires a cold migration.
Likely resolution: Select a compatible destination, establish an appropriate EVC baseline, apply a validated CPU mask where justified, or power off the VM before moving it.
Symptom: A VM moves to a newer host but not back to an older host
- Identify whether the VM was powered on while running on the newer host.
- Check whether newer CPU capabilities were exposed after that boot.
- Compare the older host against the VM's current required feature set.
Likely resolution: Power-cycle the VM under the intended EVC baseline, or keep it on hosts that satisfy its current CPU requirements.
Symptom: A hardware refresh introduces vMotion failures
- Review the CPU vendor and generation of new and existing hosts.
- Verify that the selected EVC mode is supported by every host.
- Check whether existing VMs were powered on before EVC planning was completed.
Likely resolution: Adopt a common EVC baseline and schedule the required VM power cycles before relying on unrestricted migration.
Symptom: Migration reports an NX/XD incompatibility
- Check the source VM's execution-protection presentation.
- Verify host firmware and vSphere settings affecting NX/XD availability.
- Confirm that the destination can expose an equivalent capability.
Likely resolution: Align NX/XD exposure across migration hosts, or use a planned shutdown if the guest configuration must change.
Exam-Relevant Notes
- vMotion is live migration, so the guest does not reboot and its CPU assumptions must remain valid.
- Intel-to-AMD and AMD-to-Intel vMotion is unsupported.
- Instruction-set features and feature flags matter more than matching clock speed, core count, or exact model name.
- A newer-to-older migration can fail even when both hosts use the same vendor.
- EVC provides a cluster-level common baseline by masking newer features; it does not bridge CPU vendors.
- Per-VM CPU masking is narrower than EVC and should be used only for documented, tested compatibility needs.
- NX and XD are vendor-specific names for related execution-protection capability, and their presentation must remain compatible.
- A cold migration and reboot can cause the guest to detect CPU capabilities again, but it requires downtime.
Summary
For vMotion to succeed, the destination ESXi host must provide a compatible virtual CPU environment for the already-running guest. Start with same-vendor hardware, compare CPU family and feature flags, and evaluate compatibility in the actual migration direction. Use EVC to establish a common cluster baseline, use per-VM masking only for carefully justified exceptions, and treat NX/XD exposure as part of the virtual CPU contract. When live compatibility cannot be achieved, a planned cold migration and reboot may be the appropriate solution.