Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1466465 - [RFE] Management UI can tell the user which CPU models are usable
Summary: [RFE] Management UI can tell the user which CPU models are usable
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: Frontend.Core
Version: future
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: ---
Assignee: bugs@ovirt.org
QA Contact: Lukas Svaty
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-06-29 17:33 UTC by Eduardo Habkost
Modified: 2020-04-01 14:51 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-01 14:47:29 UTC
oVirt Team: Virt
Embargoed:
tjelinek: ovirt-future?
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 822148 0 unspecified CLOSED libvirt should enforce guest CPU configuration 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 824987 1 None None None 2021-01-20 06:05:38 UTC
Red Hat Bugzilla 1199452 0 unspecified CLOSED libvirt guest CPU configuration tracker 2021-02-22 00:41:40 UTC

Description Eduardo Habkost 2017-06-29 17:33:30 UTC 
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 08:31:20 UTC 
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 17:25:37 UTC 
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 08:18:57 UTC 
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.
Comment 4 Michal Skrivanek 2020-03-18 15:46:23 UTC 
This bug didn't get any attention for a while, we didn't have the capacity to make any progress. If you deeply care about it or want to work on it please assign/target accordingly
Comment 5 Michal Skrivanek 2020-03-18 15:51:10 UTC 
This bug didn't get any attention for a while, we didn't have the capacity to make any progress. If you deeply care about it or want to work on it please assign/target accordingly
Comment 6 Michal Skrivanek 2020-04-01 14:47:29 UTC 
ok, closing. Please reopen if still relevant/you want to work on it.
Comment 7 Michal Skrivanek 2020-04-01 14:51:02 UTC 
ok, closing. Please reopen if still relevant/you want to work on it.
Note You need to log in before you can comment on or make changes to this bug.