VMware ESXi and vSphere Cluster Management

VMware Enhanced vMotion Compatibility (EVC) Explained

Learn how VMware vSphere EVC creates a common CPU baseline for vMotion, including requirements, cluster behavior, limitations, configuration, and troubleshooting.

Enhanced vMotion Compatibility (EVC) is a vSphere cluster capability that helps running virtual machines move between ESXi hosts with different processor models. EVC presents a consistent, shared CPU feature set to virtual machines, allowing vMotion between compatible hosts while preserving the differences in their physical processors.

This guide explains what EVC does, how it works with vCenter Server clusters, how to choose a baseline, and what to check before adding hosts or migrating workloads.

What Is Enhanced vMotion Compatibility?

Enhanced vMotion Compatibility (EVC) is a cluster-level feature managed through vCenter Server. It maintains CPU compatibility among the ESXi hosts in a cluster by selecting a common CPU feature set that every eligible host can support.

A CPU feature set is the collection of processor instructions and capabilities that a hypervisor can expose to a virtual machine. Newer processors may provide instructions that older processors do not. If a running VM has been using one of those instructions, moving it to an older or different processor can cause a CPU compatibility failure.

EVC addresses this problem by presenting VMs with a consistent CPU capability level. A newer host may physically support more instructions than an older host, but EVC can hide features above the selected baseline. The processors do not become physically identical; the guest-visible CPU interface becomes compatible.

Why EVC Matters for vMotion

vMotion is the live migration of a running virtual machine from one ESXi host to another. During a vMotion operation, the destination host must be able to provide a compatible virtual CPU environment.

Without EVC, two hosts can expose different CPU features. A VM running on the host with the newer feature set may use an instruction that the destination host cannot provide. vSphere can then reject the migration because the VM's CPU state cannot be safely continued on the destination.

With EVC enabled, eligible hosts use the same cluster baseline for guest-visible CPU features. A VM that uses only features in that baseline can move between those hosts, even when their physical CPU generations differ.

EVC and DRS have different jobs:

  • EVC establishes CPU compatibility by controlling which CPU features are presented to VMs.
  • DRS, or Distributed Resource Scheduler, balances workloads and can recommend or automate VM placement and vMotion actions.
  • DRS can use vMotion, but enabling DRS does not by itself solve CPU feature incompatibility.

How EVC Works

The EVC baseline

An EVC baseline is the common, guest-visible CPU feature level selected for a cluster. The baseline contains only capabilities supported by every host that is intended to participate at that level.

For example, imagine a cluster with an older processor and a newer processor from the same vendor. The newer processor supports additional instruction-set features. If both processors support baseline X, but only the newer processor supports features above X, EVC presents baseline X to the VMs.

  1. vCenter Server evaluates the CPU capabilities of the intended ESXi hosts.
  2. The administrator selects an EVC mode or baseline that all participating hosts can support.
  3. CPU feature masking or presentation prevents VMs from depending on features above that baseline.
  4. Hosts joining the cluster are configured to present the established baseline to cluster workloads.
  5. VMs can migrate between eligible hosts as long as their other vMotion requirements are also satisfied.

CPU masking means restricting or concealing processor features from a VM. It does not remove the features from the physical processor. It changes the virtual CPU interface so that workloads see a stable set of capabilities.

What the VM sees

Without EVC, a VM may see a CPU feature set that reflects the capabilities exposed by its current host. With EVC, the VM sees the common baseline instead of every feature available on an individual host.

This can reduce the number of CPU instructions available to the guest operating system or application. That trade-off is intentional: the VM gives up some newer features in exchange for broader migration compatibility.

EVC Scope and Its Relationship to Clusters

EVC is enabled and managed at the vCenter Server cluster level. It affects the ESXi hosts and workloads within the applicable cluster. It is not a per-VM feature and is not merely a DRS option.

EVC may appear during the creation of a cluster that also uses DRS, which can make the features seem connected. They remain separate settings. A cluster can use EVC to establish CPU compatibility, while DRS can be configured independently for manual, partially automated, or fully automated workload placement.

When planning cluster boundaries, group hosts that can support the same baseline and that have compatible CPU vendor families. Hardware that cannot meet the cluster's baseline generally belongs in another cluster.

EVC Function, Scope, and Limits

Area — What EVC Does — What EVC Does Not Do

CPU feature presentation — Presents a common CPU feature baseline and masks unsupported higher-level features. — Does not make different physical processors identical.

vMotion compatibility — Helps eligible VMs move between hosts that support the same baseline. — Does not guarantee vMotion if storage, networking, VM configuration, or other requirements fail.

Cluster scope — Applies to hosts and workloads in a vCenter-managed cluster. — Is not a universal setting for every host managed by vCenter Server.

DRS relationship — Supplies CPU compatibility that vMotion and DRS placement can depend on. — Does not balance resources or decide where VMs should run.

CPU vendor mixing — Supports compatible generations or families within a supported vendor grouping. — Does not make conventional Intel and AMD hosts compatible in one EVC cluster.

CPU Vendor and Family Compatibility Limits

Conventional EVC planning requires processors from the same CPU vendor family. A CPU vendor family is a compatibility grouping based on the processor vendor and supported generations, such as an Intel-only or AMD-only environment.

  • Intel and AMD processors cannot normally be mixed in one conventional EVC-compatible cluster.
  • Hosts from different generations of the same vendor may be compatible if every host supports the selected baseline.
  • Each individual host must support the chosen EVC baseline, not merely a related processor generation.
  • The oldest or least capable host that must participate often determines the highest practical baseline.

When designing a mixed-generation cluster, start with the processor capabilities of the oldest host you intend to retain. A newer host may support a higher baseline, but it must present the lower shared baseline when joining the cluster.

Selecting and Enabling an EVC Baseline

Select a baseline that every intended host can support while retaining the CPU features required by your workloads. Choosing the newest available option is not always correct; the best choice is the highest compatible level that also fits the oldest participating host and the VM requirements.

Configuration workflow in the vSphere Client

  1. Create or select a vCenter-managed cluster.
  2. Open the cluster configuration settings.
  3. Enable EVC at the cluster level.
  4. Choose an EVC mode or baseline supported by all intended hosts.
  5. Validate host compatibility before adding hosts or migrating workloads.
  6. Review VM CPU feature requirements before applying a baseline that may restrict guest-visible features.

EVC can be enabled during cluster creation or configured on an existing vCenter cluster, subject to the state of the hosts and virtual machines. The vSphere Client displays compatibility information for available modes and hosts.

Choosing for the oldest participating host

Suppose a cluster contains an older same-vendor host and a newer host. The newer host has additional instructions, but the older host does not. The selected baseline must be supported by both. After EVC is enabled, VMs see the shared baseline and can be migrated between the two eligible hosts.

If a host cannot satisfy the selected baseline, it cannot join the cluster under that configuration. The administrator must select a different compatible baseline, replace or exclude the host, or place it in a separate cluster.

Virtual Machine Considerations Before Enabling EVC

Before enabling a lower baseline, review how existing VMs have been running. A VM may have previously received access to advanced CPU instructions from its host. If the selected EVC baseline hides those instructions, the guest-visible CPU capabilities can be reduced.

  • Identify workloads that use specialized instruction sets or application-specific CPU acceleration.
  • Confirm that the selected baseline includes the CPU features required by the guest operating system and applications.
  • Consider VMs that were created or powered on before EVC was enabled and may have encountered newer host features.
  • Test critical workloads when reducing the available CPU feature level.
  • Do not assume that a successful power-on proves that every application feature requirement is satisfied.

Host Admission and Cluster Expansion

When a new ESXi host is added to an EVC-enabled cluster, vCenter Server evaluates it against the cluster's existing baseline.

  • A compatible host is configured to present the established baseline to cluster workloads, even if its physical CPU supports newer features.
  • An incompatible host is prevented from joining under that baseline.
  • A different CPU vendor family is a fundamental compatibility problem for a conventional EVC cluster.
  • The administrator must address the hardware plan, revise the baseline when appropriate, or use a separate cluster.

Example: adding a newer host

A cluster already uses a baseline supported by its current hosts. A newer same-vendor host is added. Because the newer host supports the existing baseline, it can join. EVC configures it to expose the established baseline for cluster workloads rather than exposing all of its newer CPU features to those VMs.

Example: adding an incompatible host

A proposed host does not support the selected baseline or uses a different vendor family. vCenter Server cannot admit it to the cluster under the current EVC configuration. The choices are compatible hardware, a separate cluster, or a carefully assessed baseline and VM redesign.

Host and Baseline Eligibility Checklist

Check — Why It Matters — Expected Result

All hosts use the same CPU vendor family — Conventional EVC does not make Intel and AMD processors interchangeable. — Hosts belong to one compatible vendor grouping.

Every host supports the selected baseline — The baseline must be available on every participating host. — Each host passes the EVC compatibility check.

No required VM CPU feature is masked — A lower baseline can hide instructions used by a workload. — Application and guest requirements remain satisfied.

New host is evaluated against the existing baseline — Cluster expansion must not reduce or break established compatibility unexpectedly. — The host joins only after passing the baseline check.

Troubleshooting EVC and vMotion

A host cannot be added to an EVC-enabled cluster

Likely causes:

  • The host CPU does not support the selected EVC baseline.
  • The host belongs to a different CPU vendor family from the existing cluster.

Resolution direction:

  • Compare the host's supported CPU features with the selected baseline.
  • Use hardware from the same compatible vendor family.
  • Place incompatible hardware in a separate cluster when necessary.

vMotion reports CPU incompatibility

Likely causes:

  • EVC is not enabled and the source and destination expose different CPU feature sets.
  • The source or destination host is not compatible with the active baseline.
  • The VM depends on a feature that is not consistently available on the destination.

Resolution direction:

  • Verify EVC status and the cluster baseline.
  • Confirm both hosts are members of the same eligible cluster.
  • Review VM and application CPU feature requirements.
  • Check other vMotion requirements separately; EVC addresses CPU compatibility, not every migration prerequisite.

A workload may lose an advanced CPU feature

The likely cause is that the selected baseline is lower than the CPU capabilities previously exposed to the VM. Assess the workload before applying the baseline. Select a compatible baseline that includes the required feature, or retain the workload on hardware that provides its required capabilities.

An administrator expects DRS to resolve CPU compatibility

DRS and EVC are separate features. Enable and configure EVC for CPU compatibility, then configure DRS independently for resource balancing and migration automation.

Design and Documentation Recommendations

Document the following settings when designing or operating a cluster:

  • Whether EVC is enabled or disabled.
  • The selected CPU vendor family and EVC baseline.
  • Host compatibility status and any excluded hosts.
  • VMs with specialized CPU feature requirements.
  • DRS automation level as a separate cluster setting.
  • The hardware generation that determines the lowest supported baseline.

Exam-Relevant Notes

  • EVC is configured at the vCenter Server cluster level.
  • EVC presents a common CPU feature set; it does not make physical CPUs identical.
  • The baseline is limited by the least capable participating host.
  • Hosts joining an EVC-enabled cluster must support the established baseline.
  • Conventional EVC planning uses one CPU vendor family per cluster; Intel and AMD are not mixed in the same conventional EVC-compatible cluster.
  • EVC enables CPU compatibility for vMotion, while DRS handles workload placement and automation.
  • Reducing the baseline can hide CPU instructions that a VM or application previously used.

Summary

EVC makes mixed-generation, same-vendor ESXi clusters more mobile by presenting every eligible VM with a common CPU feature baseline. vCenter Server manages that baseline at the cluster level, evaluates hosts against it, and prevents incompatible hosts from joining.

The essential planning sequence is to identify the CPU vendor family, compare every host with the intended baseline, review VM feature requirements, and distinguish EVC's compatibility role from DRS's placement role. For related reading, see Enhanced vMotion Compatibility (EVC).