<model usable='yes'>Cascadelake-Server-noTSX</model>
<model usable='no'>Cascadelake-Server</model>
The Cascadelake-Server is not usable any more in 8.3 [1] yet that is what the cluster is probably configured with.
Could you please run the following query for your cluster to be sure?
select name, cpu_name, cpu_flags, cpu_verb from cluster;
Could you please also run the virsh domcapabilities command on one of your active and running 8.2 hosts to see if they support Cascadelake-Server-noTSX?
1: https://www.phoronix.com/scan.php?page=news_item&px=Red-Hat-RHEL-8.3
Thank you,
Lucia
Hi, that CPU looks rather good to me: KVM/oVirt should love it (as would I)!
I am actually more inclined to believe that it may be a side channel mitigation issue: KVM is distingiuishing between base CPUs and CPUs with enabled mitigations to ensure that you won't accidentally migrate a VM from a 'safe' CPU to one that's vulnerable.
So I suggest you have a look at that, seen what's enabled in BIOS and via microcode updates and check that against what the cluster wants. Perhaps it may involve as little as ensuring all current patches are in (with reboots) after the update to 8.3.
E.g. you might see this when the cluster was previously running on a system with mitigations active, but now mitigations are off (e.g. because the latest microcode updates are not loaded yet).
My personal impression is that it wasn't a terribly good idea to mix mitigations and CPU capabilities, but that they didn't have time/means for a full redesign to what they might have hoped was a singular/one shot issue, before it developed into a whole family of cancers.
Bonne chance!
_______________________________________________
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-leave@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/
List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/OHLWLUG23QST3NJCVIX57RR6ZRMSY6VM/