Live migrations (aka vMotion) is still one of the most impressive features of the vSphere platform although it has been around for quite a while now. It demonstrates the superiority of virtual machines over physical servers and their independence from the underlying physical hardware.
But the hardware independence is not complete, unlike other devices CPU’s are not emulated by the hypervisor, but passed through the VM, utilising hardware virtualisation features that are built into the processor in particular vendor specific ways. As a consequence vMotion does only work between similar CPU’s of the same vendor by default.
How to disable vMotion Compatibility Checks:
Although it is not recommended; I don’t recommend it myself but for “test” environments or non-critical production environments it shouldn’t be a problem.
There are two places to configuring advanced vCenter settings in version 5.1:
- vSphere Client (fat app) in / Administration/ vCenter Settings / Advanced Settings
- vSphere Web Client / vCenter / Manage / Settings /Advanced Settings
- Adding the key config.migrate.test.CpuCompatibleWithHost with value false will completely disable all compatibility checks. This is the brute force method, and I would really not recommend doing this, because this will also suppress any warnings to be shown
- Adding the key config.migrate.test.CpuCompatibleMonitorSupport with value false will only disable checking the VMM (Virtual Machine Monitor) on the source and target hosts for supported CPU features (preventing any “product version does not support features” error messages).
- Adding the key config.migrate.test.CpuCompatibleError with value false will display all compatibility check errors as warnings only that do not prevent starting the migration (still not recommended, but at least you have been warned).
As stated prior, suppressing vMotion compatibility checks by these means is not supported by VMware!
These settings won’t give you the ability to turn EVC on, it only suppresses the errors and turns them into warnings and unlocks lock that blocks you from going further.
Why this shouldn’t be implemented in “production”
Of course there is a reason why the vMotion Compatibility checks exist and why VMware does not support disabling them: Different CPUs provide different sets of advanced CPU instructions and features. If an application or the OS running inside a VM is using a certain CPU feature and is then migrated to a host with a different CPU that does not provide this feature … guess what will happen: The application or even the whole OS inside the VM will crash.
Examples are Multimedia or compute intensive applications that use SSE extensions. These extensions are even used by Operating Systems’ kernel code. The software RAID code of certain Linux kernels e.g. do a quick benchmark at boot time to determine the most effective method for computing check sums: Imagine it decides to use SSE3 extensions for calculating RAID5 check sums. If you happen to actually use software RAID5 in such a machine and vMotion it to a host that does not provide this CPU feature then this will certainly result in an instant kernel panic, hopefully without data loss or corruption.
Should you have any questions, comments or suggestions, please don’t hesitate to comment below. If you like what you have read, please share it on your favourite social media medium.