Upgrading VM configuration makes live migrations fail

Question

Hi,

we have two different Failover Clusters of HyperV with slightly different hardware. Both clusters are running Windows Server 2022.

Cluster A has an Intel Xeon E5-2690 v4 as the CPU and Cluster B has Intel Xeon Gold 6148 as the CPU.

Now when I tried live migrating VMs from Cluster A to Cluster B (shared nothing live migration) some VMs would move and some would fail with the error messages were "some processor specific features are not supported". The Compare-VM cmdlet showing 21026 and 24004 as incompatibilities, which are from my research the error codes for processor related live migration issues. Since some of the VMs were able to be migrated, it is apparently not an issue, especially since the CPU in Cluster B is actually more recent.

After checking and researching, I finally realized that all VMs that were able to be live migrated still had VM configuration version 8.0 from the migration from HyperV 2016. All the VMs that were created on the HyperV 2022 were of course created with configuration version 10.0 and all of those cannot be live migrated to the other cluster. I've confirmed this by moving one VM back from cluster B to A and upgrading its configuration version from 8.0 to 10.0. Now it also fails while working perfectly fine before. When checking the differences between the versions here (https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/deploy/upgrade-virtual-machine-version-in-hyper-v-on-windows-or-windows-server#what-happens-if-i-dont-upgrade-the-virtual-machine-configuration-version) I feel like it should have no impact on live migrations.

And yes, enabling the compatibility option for processors does allow the VMs to live migrated, but it is not really an option to shut down these VMs right now.

Is there a solution for this issue? This honestly to me seems like a bug.

Kind regards

Answer 1

Hello!

One solution to this issue is to use the "Export" feature in Hyper-V Manager to export the VMs with the higher configuration version to a location accessible by the other cluster. Then, import the VMs into the other cluster with the lower configuration version.

Alternatively, you can also try enabling the compatibility option for processors, as you mentioned. However, this may not be a viable option for your situation.