VMotion fails because of CPU incompatibilities

When trying to do a cross vCenter migration, I run into an issue which seems to be EVC related, but might be more because of the Spectre and Meltdown patches difference between source and target ESXi host.

Situation at fase 1:
Source ESXI host at 6.5 EP12 Upd2 build 11925212
Source vCenter at 6.5 build 9451637
Cluster is at Westmere EVC level

Target ESXi host at 6.5 Upd1 build 7967591
Target vCenter at 6.5 build 8024368
Cluster is at Westmere EVC level

When doing a cross vCenter migration through PowerCLI (because the vCenters do not share PSC), all VMs at hardware level 7 and hardware level 8 can be migrated without issue. However when I migratie VMs with HW level 10 and up, I run into the following error:

Move-VM The operation for the entity “vmname” failed with the following message: “The target host does not support the virtual machine’s current hardware requirements.”. . . To resolve CPU incompatibilities, use a cluster with Enhanced vMotion Compatibility (EVC) enabled. See KB article 1003212.

After doing some research, it looks that this is what I’m running into: [http://virtualvillage.cloud/?p=794](http://virtualvillage.cloud/?p=794)

It seems this is not an EVC level issue at the cluster, but there is some difference in CPU levels because of the Meltdown and Spectre patches. Also the Hardware Level differences in the VMs making them fail or not, points to the Spectre and Meltdown patches. Therefore I tried to upgrade one of the target hosts in the cluster, so I got this new situation in which I only upgrade the target host to the same build as the source host.

I did not upgrade the target vCenter since we’re still waiting to move from 6.5u1 to 6.7 and need to remove our Nexus1000V dvSwitch first and there is a chain of other pre-requisites that we’re trying to solve right now.

Still, when migrating cross vCenter between Source and Target ESXi host, both at 6.5 EP12 Upd2 build 11925212, I run into the same issue. Could it be that the target vCenter doesn’t understand the EVC level that the new host is running and therefore still doesn’t mask the correct functions? So is a target vCenter upgrade required as well?

View Reddit by GabesVirtualWorldView Source

Related Articles


  1. 1000V. May it burn in hell. Feel your pain buddy, been there and done that.

    If you’re waiting on all the other bits to come together, can you just upgrade the target side in the interim so it is all like for like (no idea on your environment or change processes)? Great way to at least rule it out…

  2. While others touched on the Spectre/Meltdown issue, heres the full sum for EVC issues:

    * Host UEFI configurations for processor and memory must also match! If you have one host that has one option off, like C states or turbo- the bit mask will be different.
    * Upgrade to ESXi 6.7 U2 or better, and spend the time to convert vms to vmx15. Per VM EVC fixes all these issues once set to a proper level.
    * Do a thorough risk analysis for Spectre and Meltdown. Many VMs do not need it in a single tenant environment, and only critical machines really do. Domain controllers, key servers, etc. Many times you can setup specific hosts to run SCA, and others to have mitigations disabled. Considering performance hits of up to 25% or more, its worth the analysis.

  3. When you’re trying to vMotion across after getting both the hosts to the same build, are you vMotioning a hardware version 10 VM or a hardware version 8/7 VM?
    The fact that you’re running higher host builds than vCenter builds could contribute to the communication problem, I’m not sure it would be the source vCenter tho – the 9451637 is not THAT much lower than your hosts, but the 8024368 going to 11925212 I would be a little dubious about. Generally following best practices we ALWAYS want to keep our vCenter at a higher build level than our ESXi hosts. Have you considered raising the destination vCenter up to a higher build?

  4. To solve this I ended up creating… I forget the term, but resource groups I think it is. But it sounds like all I had to do was power the VMs off. I thought I did that…

  5. Put of curiosity if you open the van view in the H5 client and edit the columns to show EVC level do the problem VMs actually show as westmere?

    I recently had a similar issue and it turned out the problem vms had different evc levels even though they had only ever existed in an evc cluster.

Leave a Reply

Your email address will not be published. Required fields are marked *