when the “processor compatibility” option is enabled, I get the following error: CPU does not support the x86-64-v2.
This option is necessary because without it, there is no way to migrate a VM when it is enabled.
Has anyone encountered such a problem?
Do you have more than one node in your Hyper-V cluster? It would suggest, that when that option is enabled, it looks at all hosts’s CPU’s across the cluster, and sets it to the most common denominator. If that particular host CPU is older than 2012, that means it doesn’t have x86_64-v2 support and hence you cannot boot or use Rocky 9.
So no, you cannot use that option if that is the case. Your option in this case means it’s limited to the nodes that have higher CPU’s that are newer than 2012. Your best bet, would be to remove the older servers from the Hyper-V cluster and replace them with new ones if you want VM migration for VM’s that require newer hardware.
we don’t have a cluster, but we do have several servers with the hyper-V role. In case of maintenance work, migration of virtual machines to another server is required, and this is not possible starting from version 9 of Rocky linux (everything works on version 8)
And what are your hardware specifications of these Hyper-V servers? What CPU? Since you are getting the error, it suggests that when compatibility is enabled, the CPU is too old to boot Rocky 9 as I already explained. Rocky 8 does not have the x86_64-v2 minimal limitation, it can boot older CPU’s. So your choice is:
- Stay on Rocky 8.
- Upgrade the Hyper-V hosts with newer hardware that are a minimum of x86_64-v2.
Also note when Rocky 10 is released, it will have a minimum of x86_64-v3, so unless your Hyper-V hosts support this minimum CPU level, you won’t be able to use Rocky 10 either.
Thank you for your help.
Yes, the processor is old:
Intel(R) Xeon(R) CPU E5-2420 v2 with a frequency of 2.20 GHz
Is “Ivy Bridge EN” that Intel says to have AVX instructions and
Intel Xeon E5-2420 v2 Specs | TechPowerUp CPU Database lists:
MMX SSE SSE2 SSE3 SSSE3 SSE4.2 AVX EIST Intel 64
XD bit TXT VT-x VT-d AES-NI F16C EPT ECC HTT
Xeon X5675, a “Westmere EP” lauched 2011 (2.5 years earlier) does already support x86_64-v2. (In fact, most Intel CPUs since 2009 do support x86_64-v2.)
It is x86-64-v3 that the E5 2420v2 cannot support.
I don’t know what Hyper-V does, but if the “worst” hardware has features that the Hyper-V “compability” option does not expose to guests, then Hyper-V needs “a serious talk”.
CPU has features. Hypervisor does pass some/all features to VM guest. When guest is migrated to another host, the CPU of target host must have all the features that guest has been passed.
If the Hyper-V “plays it safe”, passes almost nothing to the guest and actually prevents migration if guest is not using that minimal feature set (even though destination CPU has all features that guest requires), then what should we think of Hyper-V?
It’s not just Hyper-V. If you have a VMware cluster of hosts, if you want migration between hosts, then it will choose the CPU features of the worst host in the cluster. So if we have a mix of new and old hosts, then the cluster will operate as if all were using the oldest CPU. Otherwise, live migration of VM’s cannot occur if CPU’s differ. This is what Hyper-V is doing when it’s placed in compatibility, so that it can migrate between new and older hosts. Dynamic Processor compatibility mode | Microsoft Learn
Even if the hosts are not operating in a cluster as such, the rule still applies when it comes to migrating VM’s.
Ahh, being limited to libvirt/KVM, which merely says “I’m sorry, Dave. I’m afraid I can’t do that.” when one attempts to migrate to lacking hardware, has saved me from such harsh realities.
Yes, hence when he has compatibility mode on Hyper-V disabled, he too cannot migrate the machine to other hardware that doesn’t match. VMware also can provided that the option that allows it is also disabled.
Hence he must stick with Rocky 8 in his current server setup, or replace the Hyper-V hosts with newer ones to allow Rocky 9 migration between hosts.
The vital question is probably:
Does Hyper-V allow migration to sufficient hardware, if VM guest is not in compatibility mode?