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 _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
