On 01/26/2014 02:40 PM, Cole Robinson wrote:
> 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
>
I've removed this upstream now, and tweaked the UI in a few other ways. From
the commit message:
- Add options in the model drop down for clear, hvdefault, and app default
- Make 'copy host' a check box, when enabled it hides the model dropdown
- Detect if the VM CPU is a copy of the host CPU
- Undocumented bit that allows passing in host-model/host-passthrough
to the model field for people that really want those settings.
- Cole
_______________________________________________
virt-tools-list mailing list
virt-tools-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/virt-tools-list
