Anyone who regularly builds VCF environments knows the problem: The installer does not set EVC (Enhanced vMotion Compatibility) during deployment, and it cannot be enforced via the API either. Broadcom documents a workaround for the deployment phase, but what do you do if the environment is already running in production—especially when the management cluster is affected and vCenter itself doesn’t know about EVC yet?
One solution uses Per-VM EVC as a bridging technology to determine the required CPU feature masks and then apply them specifically to the vCenter Server’s vmx file. The process is a bit hands-on, but reproducible and avoids the full cluster shutdown that enabling EVC at the cluster level retroactively would otherwise require.
Information Gathering as a Foundation
Before changing anything, the lowest common denominator of CPU generations in the cluster must be determined. For Intel CPUs, a look at ark.intel.com helps; for AMD, the last digit of the model number reveals the Zen generation (e.g., 7343 = Zen 3, 9015 = Zen 5). From this, the appropriate EVC level is derived—in the example, “Sapphire Rapids”. A joint compatibility overview of possible EVC modes can then be found at https://compatibilityguide.broadcom.com/search?program=cpu&persona=live
Next, a dummy VM is created (standard wizard, all defaults) and set to this exact level via Per-VM EVC. The trick: Per-VM EVC writes the complete feature mask list into the VM’s vmx file. SSH access to an ESXi host in the cluster and a look at this vmx provides all featMask.vm.cpuid.* entries needed later for vCenter. Important: Note which host the vCenter VM is currently running on and ensure the Host Client is reachable there—vCenter must be powered back on via this host later.
The Actual Procedure
Now it gets serious: All VMs in the cluster, including vCenter, are powered off. In the vCenter VM’s datastore folder, the vmx file is backed up (cp vcenter.vmx vcenter.vmx.bak) and then edited with vi. All previously copied feature mask lines are appended to the end of the file. After saving, vCenter is powered on via the Host Client.
Once vCenter has fully started, the VM’s EVC tab shows a “Custom Level”—this is expected behavior in this intermediate step. Now, in the vSphere Client at the cluster level under Configure → EVC, the desired level (here Sapphire Rapids) is set and saved. Then: Power off vCenter again, remove the inserted feature mask lines from the vmx, save the file, start vCenter once more. The EVC tab should now display the cluster level without the “Custom” designation. The cluster is now EVC-consistent, and all VMs can be powered back on.
Conclusion
The workaround isn’t a one-liner, but it closes a gap that the VCF installer (as of 9.0/9.1) leaves open. Particularly valuable: It works on the management cluster without requiring a separate vCenter for the operation. Anyone planning new VCF environments should check if the Broadcom workaround can be applied during deployment—this saves the retrofitting effort. For existing environments, the described method is currently the cleanest way to add EVC after the fact without cold-booting the entire cluster.