EVC Was Never Enabled, and Now Half the VMs Cannot Move
A cluster was built with three hosts of one CPU generation, and EVC was never enabled because it was not needed at the time. Six months later three hosts of a newer generation were added to the same cluster. Everything appears healthy: VMs created on the newer hosts run there, VMs on the older hosts run there, and vMotion works within each group. Now 12 VMs fail immediately when migrated toward an older host, with a message that the destination host's CPU is incompatible with the VM. The team proposes enabling EVC at the newest CPU baseline available in the cluster, on the reasoning that this will make all hosts consistent.
1. Explain what is actually happening to the 12 VMs, and why choosing the newest EVC baseline would make the situation worse rather than better.
Read the worked answer
What is happening
With EVC disabled, each VM is powered on with the full CPUID feature set of the host it landed on. The 12 failing VMs were powered on (or have been running) on the newer hosts and expose CPU features the older hosts do not implement. vMotion performs a CPU compatibility check against the destination host's actual capabilities - not against any cluster baseline - so migration toward an older host is refused instantly. That also explains the pattern: VMs on older hosts move fine to other older hosts, and VMs on newer hosts move fine among newer hosts.
Why the newest baseline is worse
- An EVC baseline is a mask applied at VM power-on; it cannot add capabilities to a host. A host must support every feature in the baseline to join the cluster.
- Setting the baseline to the newest generation immediately makes the three older hosts non-compliant. They would have to be removed from the cluster, which is a bigger outage than the problem you started with.
- The baseline must be the generation of the oldest host in the cluster - that is the whole point of it. Newer CPUs implement supersets, so they can mask down; older CPUs cannot mask up.
The second trap
Enabling EVC does not retroactively change the CPUID of a running VM. VMs that have already been powered on keep their original feature exposure until they are fully powered off and back on. A guest reboot is not sufficient.
2. Produce the migration plan. Be explicit about what requires downtime, what does not, and what you would verify before and after.
Read the worked answer
Before the window
- Confirm every newer-generation host supports the older baseline - it should, as a superset, but verify rather than assume.
- Inventory which VMs were powered on where, so you know which ones currently expose features above the target baseline. Expect that to be every VM that has run on a newer host since the hosts were added.
- Confirm no VM depends on a CPU instruction (compiled AVX-512 paths, vendor appliances with CPU checks) that the older baseline masks out.
The window
- Enable EVC at the baseline of the oldest host generation. vSphere requires all VMs in the cluster to be powered off to change EVC mode, so this is a planned cluster outage - communicate it as such.
- Optionally, verify host compliance after the change and before powering VMs back on.
- Power the VMs back on. This is the step that applies the mask; it is also the downtime you already scheduled.
After
- Verify a test VM migrates in both directions across generations.
- Record the baseline in the build standard and enable EVC in the cluster template, so the next host addition cannot repeat this.
- Note what did not need downtime: adding hosts, vMotion within a generation, and any storage work. The outage is caused solely by the EVC mode change plus the required power cycle.
3. One appliance vendor insists its VM requires a CPU feature that the older baseline masks out. What are the options, and which would you choose?
Read the worked answer
Options
- Per-VM EVC. Set a newer baseline on that single VM. The VM's CPUID is then defined by the VM setting rather than the cluster baseline. The trade-off is real and must be stated: the VM can only run on hosts that support its baseline, so its DRS scope and HA restart scope shrink to the newer hosts. Pair it with a host group and a DRS rule so placement is deliberate rather than accidental.
- A separate cluster with a newer or no baseline for the appliance tier. Clean isolation, but you now run two clusters and lose the ability to evacuate hosts across them.
- Stay with the cluster baseline and keep the appliance on the newest hosts without per-VM EVC, accepting that it cannot be protected as well - effectively option 1 without the guardrails.
- Push back on the vendor for a build that does not require the instruction, or that detects it at runtime. Compiled code paths that assume AVX-512 will fault with an illegal instruction when masked, so a runtime check has to genuinely exist.
Choice
Per-VM EVC plus a host group and a must-run rule, documented as an exception to the cluster standard. It keeps the cluster coherent for the 99% case, gives the appliance what it needs, and - critically - makes its restricted mobility explicit so nobody schedules a maintenance window expecting it to evacuate to an old host.
Do not hand-edit CPUID masks or use advanced settings to fake the feature. That produces a VM that migrates successfully and then crashes in production.