On 04/15/2013 01:45 AM, Cole Robinson wrote:
So here I'm not sure we even want host-passthrough in the virt-manager UI. I
know it's valuable and useful, but there's the problem that libvirt 'taints'
the VM when you set this flag. This doesn't really have any functional effect,
but it basically means that libvirt devs consider this option to be not all
that supportable. Exposing it in the UI seems like going against libvirt's wishes.
It's also quite hard to explain host-model vs host-passthrough to an end user.
We could just throw them in a combo box, but I guarantee it will have people
asking over and over what the difference between host-model and
host-passthrough is.
I'm fine with allowing this via virt-install though.
I'm not sure what the end result UI should be here. If we use host-model when
libvirt is new enough, the current UI doesn't quite fit, because we don't know
what libvirt cpu model and feature flags we are going to get until we define
the VM, so hitting the 'copy' button won't update the UI. I guess we could
change it to a checkbox.
Yes, checkbox is good for using host-model.
Currently, after clicking 'copy' button, the user still could
be able to
add/remove features or even change cpu model based on host cpu
configuration further before applying. After we change it to
a checkbox,
The part of the functionality will lose, but user could still
get what
they want by using custom mode.
Also, I don't know if host-model allows add/removing extra CPU flags, so if
host-model is selected, we might want to disable the feature list and model
drop down to make it clear they aren't editable. They should still be viewable
though so users can see the exact configuration.
libvirt will ignore the xml definition of extra feature flags
in the case of host-model.
Okay, I will modify some of my patches for the above.
Thanks.
Guannan
_______________________________________________
virt-tools-list mailing list
virt-tools-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/virt-tools-list
