Bug 1466465 - [RFE] Management UI can tell the user which CPU models are usable
[RFE] Management UI can tell the user which CPU models are usable
Status: NEW
Product: ovirt-engine
Classification: oVirt
Component: Frontend.Core (Show other bugs)
future
Unspecified Unspecified
unspecified Severity medium (vote)
: ---
: ---
Assigned To: bugs@ovirt.org
Pavel Stehlik
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-29 13:33 EDT by Eduardo Habkost
Modified: 2017-09-28 04:26 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Virt
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
tjelinek: ovirt‑future?
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 1199452 None None None 2017-06-29 13:34 EDT
Red Hat Bugzilla 822148 None None None 2017-06-29 13:33 EDT
Red Hat Bugzilla 824987 None None None 2017-06-29 13:33 EDT

  None (edit)
Description Eduardo Habkost 2017-06-29 13:33:30 EDT
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.

Related BZs:
* qemu-kvm bug 824987
* libvirt bug 822148
* libvirt tracker bug 1199452
Comment 1 Tomas Jelinek 2017-06-30 04:31:20 EDT
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?
Comment 2 Eduardo Habkost 2017-06-30 13:25:37 EDT
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.
Comment 3 Tomas Jelinek 2017-07-10 04:18:57 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.