I am not sure what's the right component for this feature suggestion, so sorry if it it's filed against the wrong product/component.
QEMU and libvirt are now able to properly tell if a CPU model or CPU configuration is runnable on a host or not, taking into account: host CPU capabilities, kernel KVM module capabilities, and QEMU capabilities. This means it should be possible to tell the user which CPU models can really be enabled in a host or cluster. This feature should be useful to prevent user mistakes like choosing "Haswell" instead of "Haswell-noTSX" when the hosts don't have TSX features available.
* qemu-kvm bug 824987
* libvirt bug 822148
* libvirt tracker bug 1199452
Im not really sure what flow you refer to.
- When you create a new cluster you have to provide a CPU while there are no hosts in it yet so the user can not be warned.
- When you add the first host to the default cluster the CPU is autodetected from this host.
- The only case I can think of is to edit the cluster? Or are you referring to some other flow?
I opened this BZ just to to make sure the oVirt team is aware of the new mechanisms, but I don't know the details of all flows in oVirt, so I can't answer which ones could benefit from it, exactly.
I can think of two possible cases, but I didn't test them with a more recent libvirt version:
1) The user is going to pick a CPU model, the system already knows which hosts are part of the cluster, and the CPU model is unusable on some (or all) of those hosts.
2) The user is going to add a host to a cluster, the CPU model was already configured for the cluster, and the host can't run that CPU model.
I see. So the place for oVirt to use it is when configuring the custom CPU type of the VM to make sure the VM will be runnable somewhere on the cluster.
Turning this to an RFE.