[virt-tools-list] virt-manager: removing CPU feature UI

Cole Robinson crobinso at redhat.com
Sun Jan 26 19:40:46 UTC 2014


Hi all,

One of the main reasons I wrote virt-xml[1] is to lighten the pressure on
virt-manager to expose every libvirt XML property that anyone might need to tweak.

I just pushed some commits upstream that remove some rarely used UI: the bits
to change ACPI, APIC, clock offset, security/label settings, and runtime CPU
pinning. I don't think anyone will complain here but speak up if you disagree.

The last bit I would like to remove is the CPU feature list. This will keep
the CPU model, copy host, and clear host buttons in place, but drop the
feature list. Here's my reasoning:

- It's not that useful. The only two nice things I can think about it are 1)
you get to see what features you VM CPU defines which is mildly interesting,
and 2) you can use it to set x2apic.

1) While interesting, seeing the features isn't that useful. And if someone
needs it, they can get the info from the command line with dumpxml
--update-cpu and cpu-baseline, although admittedly it's not that convenient.
But still I don't think it's that important

2) x2apic should be handled by qemu/libvirt to be set by default, which I
believe is the eventual plan. If this is sufficiently important to people in
the mean time, we could add a single option like 'enable x2apic'. But only if
its really important. virt-xml also makes adding x2apic trivial: virt-xml
$domain --cpu +x2apic

- If we keep it, it needs some work: 1) Exposing all the CPU flag modes is
overkill, for one thing, so we should remove them. 2) It works awkwardly now
with host-model and host-passthrough: host-passthrough makes it look like you
can edit features when it won't stick after hitting 'apply'. 3) Right now we
parse static /usr/share/libvirt/cpu_map.xml to get a list of all features:
this isn't a sustainable way to do things, since it may be inaccurate for
remote connections, or the file might be located somewhere else. Libvirt
provides APIs nowadays to list all CPU models for a connection, but doesn't
provide one for all CPU flags. If we drop the CPU flags UI, we don't need
libvirt to add any new API, and we can stop depending on cpu_map.xml.

So, does anyone have any objections to removing this UI beyond what I've
listed above?

Thanks,
Cole

[1] http://www.redhat.com/archives/virt-tools-list/2014-January/msg00179.html




More information about the virt-tools-list mailing list