VMware ESXi and vSphere Cluster Management
VMware vSphere Enhanced vMotion Compatibility (EVC) Explained
Learn how VMware vSphere EVC standardizes VM CPU features, supports vMotion across compatible CPU generations, and how to plan, configure, validate, and troubleshoot it.
Enhanced vMotion Compatibility (EVC) is a vCenter Server cluster capability that gives virtual machines a consistent set of CPU features. This allows vMotion between ESXi hosts that use different, but compatible, CPU generations.
EVC is especially useful during hardware refreshes. Older and newer hosts can temporarily coexist in one cluster, allowing workloads to move between them while administrators replace hardware in stages.
What Is Enhanced vMotion Compatibility?
EVC standardizes the CPU feature set exposed to virtual machines in a vSphere cluster. It does this by using CPU feature masking: processor capabilities that are not available on every host are hidden from the VMs.
The result is a shared EVC baseline. A VM sees the applicable baseline whether it runs on an older host or a newer host in the same EVC-enabled cluster. Because the VM does not depend on host-specific newer instructions, vMotion is less likely to fail because of a CPU feature mismatch.
EVC does not make unrelated processor architectures compatible. In particular, Intel and AMD hosts cannot be combined in the same EVC cluster. EVC only creates a common feature level among compatible processors from the same vendor.
How EVC Works
CPU feature masking
Modern CPUs expose instruction sets and hardware capabilities that can differ between models and generations. A virtual machine that starts on a newer processor may otherwise observe features unavailable on an older destination host.
EVC masks selected newer features so that the VM receives a stable, compatible virtual CPU presentation. The physical host may support more features, but those additional capabilities are not exposed to VMs when they fall outside the selected baseline.
The common CPU feature set
The EVC baseline is the CPU capability level that every ESXi host in the cluster can support. The baseline must be low enough for the oldest required host, while still meeting workload requirements.
For example, suppose three same-vendor hosts have progressively newer CPUs:
- Host A supports the oldest feature level.
- Host B supports the feature level of Host A plus additional instructions.
- Host C supports all features of Host B plus newer instructions.
The cluster can select a baseline supported by Host A, B, and C. VMs then receive that shared feature set regardless of their current host.
Why this prevents vMotion failures
Without EVC, a VM powered on or resumed on a newer CPU may use features that the destination host does not provide. vMotion can then report CPU incompatibility. With an appropriate EVC baseline already applied, the VM is presented with only features shared by the cluster hosts, removing that particular incompatibility.
| Concept | Purpose | Scope | Key Limitation |
|---|---|---|---|
| EVC | Creates a consistent virtual CPU feature presentation. | vCenter Server cluster | Does not make different CPU vendors or unrelated architectures compatible. |
| EVC baseline | Defines the common CPU feature level. | All applicable VMs and hosts in the cluster | Must be supported by every host that joins. |
| CPU feature masking | Hides features unavailable on all hosts. | Virtual CPU presentation | Advanced instructions may be unavailable to workloads. |
| vMotion | Moves a running VM between ESXi hosts. | Source and destination hosts | Still requires other vMotion prerequisites, such as networking and storage compatibility. |
EVC, vMotion, and DRS
EVC is configured at the vCenter Server cluster level. It is not a DRS-only feature. Administrators often enable it while creating or managing a DRS cluster, but EVC also benefits manually initiated vMotion operations.
DRS, or Distributed Resource Scheduler, decides where workloads should run and can automate migrations. EVC makes the CPU feature presentation compatible across hosts. DRS does not automatically solve a CPU feature mismatch.
| Feature | EVC | DRS |
|---|---|---|
| Primary purpose | Provides a common CPU feature baseline. | Balances workloads and determines placement. |
| Migration relationship | Removes certain CPU compatibility barriers. | Can initiate or recommend vMotion. |
| Scope | Cluster CPU compatibility configuration. | Cluster resource scheduling and automation. |
| Can operate without the other? | Yes, EVC is not dependent on DRS. | Yes, but CPU compatibility still must exist for a migration. |
CPU Vendor and Family Limitations
All hosts in one EVC cluster must use processors from the same CPU vendor. A CPU vendor is the processor manufacturer, such as Intel or AMD.
- Different Intel CPU generations may be combined when a supported common baseline exists.
- Different AMD CPU generations may be combined when a supported common baseline exists.
- Intel and AMD hosts cannot be mixed in one EVC cluster.
- The selected vendor-specific baseline must be supported by every current and planned host.
| Condition | Supported or Unsupported | Reason | Administrative Action |
|---|---|---|---|
| Different CPU generations from the same vendor | Supported when a common baseline exists. | EVC can mask newer features to establish a shared level. | Choose a baseline supported by all hosts and verify vCenter validation. |
| Intel and AMD hosts in one cluster | Unsupported. | EVC cannot establish one shared vendor baseline for both. | Use separate clusters. |
| Host supports the selected baseline | Supported. | The host can present the required feature level. | Allow admission after compatibility checks pass. |
| Host does not support the selected baseline | Unsupported for that cluster. | The host cannot provide the features required by the baseline. | Use a compatible host, redesign the cluster, or assess a lower baseline. |
| VM requires a feature masked by the baseline | Potentially unsuitable. | The guest workload may lose access to a required instruction. | Test the workload or place it in a cluster with a higher suitable baseline. |
Choosing an EVC Baseline
Normally, choose the initial baseline according to the oldest CPU generation that must remain in the cluster. This is common during a rolling hardware upgrade, when old and new hosts coexist temporarily.
A lower baseline provides broader host compatibility, but it can hide newer CPU instructions from VMs. A baseline that is too new prevents older hosts from joining or remaining compatible.
- Lower baseline: supports more mixed generations, but exposes fewer CPU features.
- Higher baseline: exposes more capabilities, but limits the hosts that can participate.
- Future planning: include replacement and expansion hosts, not only the hosts currently installed.
Review vCenter Server compatibility checks and warnings before applying a mode. Do not lower a baseline merely to admit an older host without first assessing applications and guest operating systems.
Effects on Hosts and Virtual Machines
Hosts joining an EVC cluster
When a host joins an EVC-enabled cluster, vCenter checks its CPU vendor and capabilities against the configured baseline. A host that cannot satisfy the baseline cannot join the cluster.
A compatible host is configured to present the cluster's EVC CPU feature baseline to its VMs. This makes the host suitable for vMotion with other compatible members.
Existing and new virtual machines
EVC controls the CPU features exposed to guest operating systems and applications. A workload that relies on advanced instructions may be affected if those instructions are hidden by the selected baseline.
Changing a VM's virtual CPU feature presentation generally requires the affected VM to be powered off and restarted. Plan a maintenance window when enabling or changing a baseline could alter the features presented to powered-on VMs.
Validate guest operating system and application requirements before lowering a baseline. CPU-intensive applications, cryptographic software, media processing, scientific workloads, and other optimized software may depend on specific instruction sets.
Requirements and Pre-Enable Planning
| Check | Why It Matters | How to Validate |
|---|---|---|
| vCenter Server is available | EVC is a vCenter cluster capability. | Confirm the hosts are managed in the intended vCenter inventory. |
| Target cluster contains ESXi hosts | The baseline must be evaluated against host CPU capabilities. | Review cluster membership and host hardware details. |
| CPU vendors match | Intel and AMD cannot share an EVC cluster. | Compare processor vendor information for every host. |
| Common baseline exists | Every host must support the selected level. | Use vCenter compatibility checks and review warnings. |
| Workloads are assessed | Masking may remove instructions used by an application. | Review vendor requirements and test representative workloads. |
| Restart plan exists | Changed CPU features may require a VM power cycle. | Schedule maintenance for affected VMs. |
| Future hosts are considered | A later host addition can fail if it cannot support the baseline. | Check planned hardware against the selected mode. |
High-Level EVC Configuration Workflow
- Review the CPU vendors, models, and generations of current and planned ESXi hosts.
- Determine the lowest common supported baseline, normally starting with the oldest host that must remain.
- Create or select the target vSphere cluster.
- Open the cluster configuration settings in the vSphere Client.
- Locate the VMware EVC configuration section and enable EVC.
- Select the appropriate vendor-specific EVC mode and baseline.
- Review compatibility validation results and resolve warnings before proceeding.
- Apply the setting and perform required VM shutdowns and restarts when the virtual CPU feature set must change.
- Verify host admission and test vMotion between representative older and newer hosts.
- Document the baseline, its rationale, supported host generations, and restrictions for future additions.
vSphere Client workflow
1. Select the target vCenter cluster.
2. Open Cluster Configuration.
3. Locate VMware EVC.
4. Enable EVC.
5. Select the matching vendor mode and baseline.
6. Review validation warnings.
7. Apply the configuration.
8. Restart affected VMs when required.
9. Test vMotion between host generations.Exact labels can vary by vSphere release and by whether EVC is being enabled for a new or existing cluster. Treat the compatibility checks in the vSphere Client as authoritative for the installed version.
Operational Validation and Monitoring
- Test vMotion from an older representative host to a newer host and back, when operationally appropriate.
- Check host compatibility before adding replacement or expansion hosts.
- Monitor guest operating systems, applications, performance, and error logs after a baseline change.
- Record the selected baseline in cluster and hardware-refresh documentation.
- After older hosts are retired, reassess the baseline. A higher baseline may then make newer CPU features available to VMs, subject to workload testing and required VM restarts.
Practical Examples
Rolling host hardware upgrade
A cluster contains older Intel hosts and new Intel hosts with additional CPU instructions. Select a baseline supported by the older hosts. Running VMs can then vMotion between both generations while the old hardware is gradually replaced.
Preventing a vMotion compatibility failure
A VM started on a newer host would otherwise see CPU features unavailable on an older destination. With a suitable EVC baseline applied before the VM starts, the VM sees only the shared feature set and can migrate between compatible hosts.
Incompatible CPU vendors
An administrator attempts to place AMD and Intel hosts in one EVC cluster. EVC cannot establish a shared vendor baseline, so the hosts must be organized into separate clusters.
Host too old for the configured mode
A cluster uses a baseline intended for newer processors. An older host fails admission because it cannot support that baseline. The administrator must use compatible hardware, redesign the cluster, or select a lower baseline after evaluating its effects.
Advanced instruction dependency
An application depends on an instruction set available only on recent CPUs. Lowering the baseline could hide that feature after the VM is restarted. Test the application first or keep it in a cluster with an appropriate higher baseline.
Troubleshooting EVC
A host cannot be added to an EVC-enabled cluster
Likely causes include a different CPU vendor, an unsupported CPU generation, or insufficient features for the selected baseline.
- Confirm that the processor vendor matches the existing cluster hosts.
- Compare the host's CPU capabilities with the selected EVC mode.
- Review vCenter compatibility warnings.
- Use a compatible host, redesign the cluster, or consider a lower baseline only after assessing every VM and application.
vMotion reports CPU incompatibility
Possible causes include disabled EVC, incompatible source and destination CPUs, a VM powered on before the intended baseline was applied, or different CPU vendors.
- Verify cluster EVC configuration and host membership.
- Confirm both hosts support the same baseline.
- Power off and restart the VM if it must receive a revised virtual CPU feature set.
- Move the workload to a compatible same-vendor cluster if the vendors differ.
An application loses a capability after a baseline change
The application may rely on a CPU instruction hidden by the lower baseline.
- Identify the required CPU feature from application documentation or testing.
- Test the workload against the selected baseline.
- Use a higher-baseline cluster after incompatible hosts are retired, or keep the workload on hardware that exposes the required feature.
DRS does not fix CPU compatibility
DRS manages placement and may automate vMotion, but it does not create a shared CPU feature set. Configure EVC to establish CPU compatibility, then allow DRS to make placement decisions within that compatible environment.
Exam-Relevant Notes
- EVC is configured at the vCenter Server cluster level.
- EVC masks selected CPU features; it does not convert Intel processors into AMD processors or make unlike architectures compatible.
- Intel and AMD hosts cannot be mixed in one EVC cluster.
- The baseline must be supported by every host in the cluster.
- A lower baseline improves mixed-generation compatibility but may hide newer instructions.
- DRS and EVC have different roles: DRS schedules workloads, while EVC provides CPU compatibility.
- Changing the CPU feature presentation may require VM shutdown and restart.
Summary
EVC provides a common CPU feature baseline for VMs in a vCenter-managed cluster. By masking features that are not available on every same-vendor host, it supports vMotion across compatible CPU generations and is valuable during rolling hardware upgrades.
Successful EVC planning requires matching CPU vendors, selecting a baseline supported by all required hosts, assessing application instruction-set requirements, following vCenter validation results, and testing migrations after configuration. When older hosts are finally removed, reassess the baseline so workloads can use newer CPU capabilities where appropriate.