On Tue, Sep 24, 2013 at 08:03:45AM -0400, Cole Robinson wrote: > On 09/24/2013 02:49 AM, Hu Tao wrote: > > On Mon, Sep 23, 2013 at 02:30:53PM -0400, Cole Robinson wrote: > >> On 09/23/2013 07:17 AM, Hu Tao wrote: > >>> On Tue, Apr 23, 2013 at 05:20:12PM +0200, Jiri Denemark wrote: > >>>> On Tue, Apr 23, 2013 at 10:47:58 -0400, Cole Robinson wrote: > >>>>> On 04/23/2013 08:06 AM, Martin Kletzander wrote: > >>>>>> On 04/23/2013 01:56 PM, Guannan Ren wrote: > >>>>>>> On 04/23/2013 07:37 PM, Martin Kletzander wrote: > >>>>>>>> On 04/20/2013 10:09 PM, Cole Robinson wrote: > >>>>>>>>> On 04/18/2013 03:47 AM, Guannan Ren wrote: > >>>>>>>>>> v1 to v2: > >>>>>>>>>> removed UPDATE_CPU flag checking > >>>>>>>>>> renamed helper function name from reset() to clear_attrs() > >>>>>>>>>> change the check box to be labeled 'Use host CPU model' > >>>>>>>>>> remove the lightbulb icon, use tooltip instead > >>>>>>>>>> reword the tooltip from Cole's > >>>>>>>>>> remove the WARN image icon from UI > >>>>>>>>>> > >>>>>>>>>> Add a checkbox for 'host-model' mode and removed 'Copy host CPU > >>>>>>>>>> configuration' > >>>>>>>>>> button. > >>>>>>>>>> > >>>>>>>> Sorry for not catching this thread earlier, but IIUC, the 'host-model' > >>>>>>>> doesn't make up for the button. XML is saved with 'host-model' then, > >>>>>>>> right? > >>>>>>>> > >>>>>>>> Unfortunately, I can't see that easily right now as git virt-manager > >>>>>>>> consistently crashes for me on all VMs and bare metal as well and I made > >>>>>>>> that one of my priorities in order to speed up the bug hunt on it. > >>>>>>>> > >>>>>>> > >>>>>>> Martin, I am using virt-manager git head now, it seems fine for me. > >>>>>>> Is there anything wrong about 'host-model', I can't quite follow you > >>>>>>> here. > >>>>>>> > >>>>>>> Guannan > >>>>>>> > >>>>>> > >>>>>> I was just wondering if dropping the button isn't a bad idea, some guest > >>>>>> OS might have problems when it is ran on different CPU, which is what > >>>>>> might happen with host-model after destroy/start, but would be avoided > >>>>>> with 'Copy host configuration'. I'm not saying 'host-model' is wrong, > >>>>>> we definitely want the support for that. > >>>>>> > >>>>> > >>>>> Hmm, how would host-model change CPU between destroy/start... like a libvirt > >>>>> update supporting more flags? I didn't think about that, and it is > >>>>> problematic. Libvirt goes to great lengths to try and preserve hardware config > >>>>> for a VM across libvirt updates, host-model potentially throws that out the > >>>>> window... > >>>>> > >>>>> Unless there's some clever way of getting around that it makes me think > >>>>> host-model just doesn't fit in the UI. Trying to explain all the nuances of > >>>>> this stuff in the current UI is impossible, so until we come up with something > >>>>> different we should go with the safest bet, which is only providing the old > >>>>> button press behavior. > >>>> > >>>> I agree that currently copying host CPU XML into guest CPU is safest > >>>> than using host-model (which is just a shortcut for it but the config is > >>>> not preserved after domain shutdown). However, host-model will be > >>>> improved (hopefully soon) to provide more. And I think we (libvirt) > >>>> should come up with something that would preserve the configuration, > >>>> too. > >>> > >>> If we preserve cpu configurations when host-model is specified, what to > >>> do with situations where the preserved configurations are different with > >>> what host-model gets? > >>> > >>> - VM is copied to another host with a different cpu. The new cpu may > >>> have all features in preserved configurations, or may not. Using > >>> preserved configurations may fail to start VM. > >>> > >>> - VM is migrated to another host with a different cpu. Same as above. > >>> > >> > >> Yes, without host-model handling those bits for us, virt-manager would need to > >> explicitly handle it. Thankfully libvirt already has APIs that could help us > >> here. But really I'm less concerned with cross host, non-uniform hardware > >> migration compatibility than I am with a libvirt upgrade implicitly changing > >> guest hardware. > >> > >>> - libvirt is updated to support more flags. It's better to update the > >>> preserved configuration. > >>> > >> > >> If libvirt supports more flags, we update libvirt, restart VM, guest sees the > >> CPU is different... wouldn't this cause Windows reactivation? > > > > Not tested. But the main concern is that guest should not be affected by > > changes caused by host-model during migration, libvirt update, etc., > > right? It seems that we have only one option left, use preserved > > configuration in such cases, which effectively makes host-model a > > one-time definition and turns it into custom mode at the first time, > > which is almost like the ``copy host CPU configuration'' button, which > > is already there. > > > > Yeah I think that's what Jiri was proposing. > > > I'm wondering the purpose of host-model when it was firstly introduced. > > Handling preserved configuration in libvirt will probably make > > host-model a different thing, thus brings compatibility issues. > > > > I think it was meant to be a libvirt approximation of -cpu host, but > unfortunately the current implementation is less complete than -cpu host but > has some of the same problems. Maybe _all_ of the same problems, but I'd have > to look to see if libvirt does something special WRT host-model and migration. 'host-model' is intended to be a migration safe version of 'host-passthrough' since it will use explicit args on the CLI, instead of 'cpu host' and can thus guarantee the same args are used across migration. The VIR_DOMAIN_XML_UPDATE_CPU flag is used to update the XML from 'host-model' to reflect the raw features and this is used during migration IIRC. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
