VMware ESXi and vSphere Cluster Management

VMware Enhanced vMotion Compatibility (EVC) Requirements

Learn the CPU, firmware, vMotion networking, vCenter, and ESXi requirements for enabling VMware Enhanced vMotion Compatibility.

Enhanced vMotion Compatibility (EVC) is a VMware vSphere cluster feature that creates a common CPU feature baseline for virtual machines. It allows vMotion between hosts with different processor generations when those hosts share a supported compatibility level.

This guide covers the requirements to check before enabling EVC, how EVC relates to vMotion and DRS, and how to troubleshoot common compatibility failures.

What Enhanced vMotion Compatibility Does

Enhanced vMotion Compatibility (EVC) applies a common CPU feature set to the hosts in a vCenter-managed cluster. Newer processors may support instructions that older processors do not. If a running virtual machine uses one of those newer instructions, moving it to an older host could fail.

EVC solves this CPU-generation problem through CPU feature masking. Feature masking suppresses selected newer processor features so that virtual machines see only the instructions allowed by the selected EVC baseline.

An EVC baseline, also called an EVC mode, represents a CPU generation and feature level. The selected baseline must be supported by every host in the cluster. A newer host can normally operate with an older baseline because it has the necessary older features, while an older host cannot provide features introduced by a newer generation.

EVC, vMotion, and DRS: Different Responsibilities

Feature — Primary purpose — What it does not solve

EVC — Provides a common CPU feature baseline across cluster hosts — Does not create vMotion networking or choose VM placement

vMotion — Transfers a running virtual machine from one ESXi host to another — Does not make incompatible CPU generations compatible

DRS — Recommends or performs VM placement and migration based on cluster policy and resources — Does not change CPU feature exposure

DRS affinity and anti-affinity rules — Keep selected VMs together or separate them across hosts — Can restrict destinations even when EVC and vMotion are otherwise ready

A successful migration therefore requires more than EVC. The source and destination must have compatible CPU exposure, working vMotion connectivity, suitable storage and device configuration, and no placement rule that excludes the destination.

CPU Vendor and Processor-Family Requirements

All hosts must use the same CPU vendor

Every host in one EVC cluster must use processors from the same vendor. Intel and AMD processors cannot be combined in a single EVC cluster because they expose different processor architectures and feature sets.

Host CPU combination — EVC eligibility — Reason or action

Intel plus Intel of different supported generations — Potentially eligible — Select a baseline supported by every Intel host, including the oldest one

AMD plus AMD of different supported generations — Potentially eligible — Select a baseline supported by every AMD host, including the oldest one

Intel plus AMD — Not eligible for one EVC cluster — Separate the hosts into same-vendor clusters or use another planned workload migration method

Hosts below the applicable historical processor minimum — Not eligible for the relevant historical EVC requirement — Replace, separate, or otherwise exclude the incompatible host

Different generations can participate

Different processor generations from the same vendor may participate when they belong to a supported processor family and share an available EVC baseline. The practical rule is to select the newest baseline that every current host supports, not the highest mode supported only by the newest server.

Historically, the minimum processor generations associated with EVC were:

Intel Core 2 microarchitecture or later.
First-generation AMD Opteron processors or later.

These historical minimums do not guarantee that a particular EVC mode is available in a current environment. Baseline availability depends on the ESXi and vCenter versions and on the CPUs installed in every host. Always verify the applicable VMware interoperability and EVC support matrices for the versions and hardware being deployed.

Example: phased Intel host refresh

Suppose a cluster contains older Intel Core 2-generation hosts and newer Intel hosts. The newer servers may support additional CPU instructions, but the cluster should use an EVC baseline that the oldest host supports. Newer hosts then expose the common older feature set to VMs, allowing workloads to move during the hardware refresh.

Host Firmware and Processor Feature Prerequisites

Required processor capabilities must be enabled consistently in the BIOS or UEFI firmware of every participating host. Check each server individually because firmware defaults can differ between models or after a hardware replacement.

Hardware-assisted virtualization: Enable Intel VT-x on Intel systems or AMD-V on AMD systems.
Execute protection: Enable Intel Execute Disable, commonly called XD, or AMD No eXecute, commonly called NX.
Consistent configuration: Apply compatible firmware settings across all hosts and reboot hosts when the platform requires a restart before ESXi can detect the change.

Hardware virtualization extensions support the processor virtualization mechanisms used by the hypervisor. XD and NX provide execute-protection capabilities that are part of the historical EVC prerequisites. Inconsistent settings can prevent a host from matching the cluster baseline or can make a host unsuitable for compatible virtual-machine execution and migration.

Firmware checklist

Record the CPU vendor and model for every host.
Enter each host's BIOS or UEFI configuration.
Enable Intel VT-x or AMD-V.
Enable Intel XD or AMD NX.
Save changes and reboot when required.
Recheck the host in vCenter after ESXi has started.

vMotion Networking Is Still Required

EVC does not replace vMotion networking. Each ESXi host must have an operational vMotion network path to the other participating hosts.

A VMkernel adapter is an ESXi networking interface used for host services. For vMotion, verify that each host has a VMkernel adapter with the vMotion service enabled. The interfaces must have mutual network reachability, appropriate VLAN or routing configuration, and working physical uplinks.

vMotion configuration checks

Create or verify a VMkernel adapter on every host.
Enable the vMotion service on the appropriate VMkernel adapter.
Confirm that the vMotion addresses and network paths are reachable between all participating hosts.
Check switch ports, VLAN configuration, routing, MTU settings, and firewall controls when connectivity is uncertain.
Confirm that the host is connected and responding in vCenter.

A cluster can have a valid EVC mode and still fail to migrate a VM if the vMotion VMkernel path is missing, disconnected, or incorrectly configured.

vCenter-Managed Cluster Requirement

EVC is configured at the cluster level through vCenter Server. vCenter Server is the centralized management platform used to create and manage the EVC-enabled cluster, evaluate host compatibility, and coordinate cluster operations.

Standalone ESXi hosts that are not managed as members of a vCenter cluster cannot use cluster EVC. The hosts must be placed in the relevant vCenter inventory and added to a cluster where EVC can be configured.

This management relationship matters because EVC, vMotion, and DRS operate across a coordinated cluster inventory:

vCenter manages the hosts as members of one cluster.
The cluster evaluates the CPU capabilities reported by each host.
An administrator selects an EVC baseline available to all hosts.
vMotion can then use the common CPU presentation when other migration requirements are also satisfied.
DRS may recommend or perform placement changes, subject to rules and destination eligibility.

ESX and ESXi Software Version Requirements

The historical minimum requirement was ESX/ESXi 3.5 Update 2 or later on all participating hosts. This requirement describes the original supported software boundary and should not be treated as a complete qualification for a modern deployment.

In a current environment, hosts should run supported ESXi versions that are compatible with the managing vCenter Server. The vCenter and ESXi versions, hardware platforms, processor features, and available EVC modes must be evaluated together.

EVC Requirement Checklist

Requirement — Applies to — Validation goal — Impact if unmet

Same CPU vendor — Every host in the cluster — All processors are Intel or all are AMD — Intel and AMD hosts cannot share one EVC cluster

Supported CPU family and generation — Every host — All hosts share at least one available EVC baseline — No common baseline can be selected, or an incompatible host must be removed

Hardware virtualization enabled — Every host's BIOS or UEFI — Intel VT-x or AMD-V is enabled and recognized — Host may fail compatibility validation

NX or XD enabled — Every host's BIOS or UEFI — AMD NX or Intel XD is enabled and recognized — Host may fail the historical EVC prerequisites or compatible execution checks

vMotion networking configured — Every ESXi host — Each host has a reachable vMotion VMkernel path — Live migration fails even if CPU compatibility is valid

vCenter-managed cluster — Cluster inventory — Hosts are managed by vCenter and placed in one cluster — Cluster EVC cannot be configured for standalone hosts

Supported ESX/ESXi version — Every participating host and the managing vCenter — Software versions are supported together — EVC modes or cluster operations may be unavailable or unsupported

Pre-Enable Validation and Baseline Selection

Before enabling EVC, inspect every current host and any host planned for addition. The baseline must be supported by all hosts that will participate in the cluster, not merely by the hosts currently carrying the most important workloads.

Inventory the CPU vendor, family, generation, and model of every host.
Confirm that all hosts use the same CPU vendor.
Verify the BIOS or UEFI settings for hardware virtualization and NX/XD.
Confirm that the ESXi versions are supported with the managing vCenter Server.
Verify the vMotion VMkernel adapter and network reachability on every host.
Review the EVC modes offered by vCenter and identify the highest common mode.
Check every host for compatibility with the proposed mode.
Resolve incompatibilities before enabling EVC.
Consider future hosts before choosing the baseline.

When hosts support different generations, choose the newest common baseline. Selecting a mode supported only by newer hosts would leave the older host unable to join or operate under that mode.

Powered-on virtual machines

Virtual machines that were already powered on may need to be powered off and restarted before they run with the newly selected EVC CPU baseline. Plan this restart according to the workload's maintenance requirements. Do not assume that changing the cluster mode immediately changes the CPU feature presentation of every already-running VM.

Plan before adding newer hosts

EVC is most useful when planned before a hardware refresh, cluster expansion, or workload move. Decide whether future hosts can support the selected baseline before adding them. If a planned server cannot provide or accept the cluster's common CPU feature level, place it in another compatible cluster or revise the migration plan.

Relationship to DRS Affinity Rules

EVC makes migration technically possible from a CPU-compatibility perspective; it does not determine VM placement. DRS affinity rules are placement rules that keep selected VMs together, while anti-affinity rules keep selected VMs apart.

For example, EVC may make every host CPU-compatible, but an anti-affinity rule can still prevent a VM from moving to a particular host. A VM-and-host affinity rule, resource constraint, storage limitation, attached device, or other destination requirement can also restrict placement.

When a VM cannot migrate after EVC is enabled, review both CPU compatibility and placement policy. Specifically, inspect DRS affinity and anti-affinity rules rather than assuming that EVC controls all migration decisions.

Practical Configuration Outline

Host BIOS or UEFI

Enable the platform hardware virtualization feature: Intel VT-x or AMD-V.
Enable Intel XD or AMD NX.
Save firmware changes.
Reboot the host if required.

ESXi vMotion networking

Create or verify a VMkernel adapter on each host.
Enable vMotion on the selected VMkernel adapter.
Ensure all participating hosts have reachable vMotion network paths.

vCenter cluster EVC

Place the hosts in a vCenter-managed cluster.
Review the EVC modes and compatibility checks presented by vCenter.
Choose a baseline supported by every host in the cluster.
Enable EVC only after reported host incompatibilities have been resolved.

Troubleshooting EVC and Migration Problems

No EVC baseline is available

Likely causes:

The cluster mixes Intel and AMD processors.
One host's CPU is too old for the available baseline.
A required virtualization or NX/XD feature is unavailable or disabled on a host.

Resolution: Review the CPU vendor and generation on every host. Correct firmware settings, select a lower common baseline when appropriate, or remove and separate incompatible hosts.

EVC cannot be enabled because one host is incompatible

Likely causes:

The selected mode is newer than the oldest host supports.
The host is running an unsupported ESX/ESXi release.
BIOS or UEFI virtualization features are disabled.

Resolution: Use a lower baseline supported by all hosts, update the host software where supported, or enable the required firmware features and revalidate the host.

A VM still cannot use vMotion after EVC is enabled

Likely causes:

The vMotion VMkernel adapter is missing, disconnected, or incorrectly configured.
A DRS affinity or anti-affinity rule blocks the destination host.
The destination has a storage, device, resource, or VM configuration constraint unrelated to CPU compatibility.

Resolution: Validate the vMotion network path, check destination eligibility, review DRS rules, and then investigate other vMotion compatibility checks.

The VM does not show the expected EVC CPU level

A virtual machine that was running before EVC was enabled or changed may need a guest shutdown and power-on cycle before it receives the new exposed CPU baseline. Follow the workload's maintenance procedure and plan the restart where required.

Key Takeaways

EVC masks newer CPU instructions to expose a common baseline across hosts.
All hosts in one EVC cluster must use the same CPU vendor.
Different same-vendor generations can participate only when they share a supported baseline.
The historical minimums were Intel Core 2 microarchitecture or later and first-generation AMD Opteron or later.
Intel VT-x or AMD-V and Intel XD or AMD NX must be enabled in host firmware.
Every host needs working vMotion networking through a reachable vMotion-enabled VMkernel adapter.
EVC requires a vCenter-managed cluster; standalone hosts cannot use cluster EVC.
The historical software minimum was ESX/ESXi 3.5 Update 2 or later, but modern deployments require current interoperability validation.
Powered-on VMs may require a restart to receive a newly selected CPU baseline.
EVC enables CPU compatibility, while vMotion performs the transfer and DRS controls placement policy.

For a concise reference, return to the VMware EVC requirements guide when planning a cluster expansion or host refresh.