[virt-tools-list] [PATCH 3/3] add a checkbox for cpu host-model mode, remove 'copy' button

Cole Robinson crobinso at redhat.com
Wed Apr 17 17:32:39 UTC 2013


On 04/16/2013 07:02 AM, Guannan Ren wrote:
> If the host-model is selected, disable the cpu model drop down
> and features list. They still show what exact configuration the
> host-model is using.
> For the old libvirt which doesn't support <cpu mode='host-model'/>
> virt-manager still copy cpu configs from caps XML to domain XML.
> If a certain libvirt version supports host-model, but the UPDATE_CPU
> flag doesn't exist, a WARN image will show up on UI to give a hint.
> ---
>  ui/vmm-details.ui      | 246 ++++++++++++++++++++++++-------------------------
>  virtManager/details.py |  44 +++++----
>  virtManager/domain.py  |  17 ++--
>  3 files changed, 156 insertions(+), 151 deletions(-)
> 

UI generally looks fine, nice work.

I'd change the check box to be labeled 'Use host CPU model'.
I'd remove the lightbulb icon, and just stick the tooltip on the checkbutton.
I'd slightly reword it to:

Use CPU model which most closely matches the host. This gives maximum
functionality and performance.

There's a problem here with using host-model though, but maybe it isn't really
virt-manager's problem. The majority of CPU flags require host HW support
before they can be offered to the guest. There is at least x2apic though which
we want to enable unconditionally, since they are 1) emulated, 2) give a
performance improvement, and 3) don't have any known side effects. How is
virt-manager supposed any client app supposed to handle this?

We aren't far from a point where host-model or some equivalent will be the
default, but where does that leave x2apic?

Maybe the solution is to have qemu enable it automagically, or libvirt to add
it to cpu model definitions, but I'm sure that has side effects as well. Maybe
Jirka has thoughts.

- Cole




More information about the virt-tools-list mailing list