[virt-tools-list] [PATCH v2 0/3] add cpu mode 'host-model' support

Tue Sep 24 12:09:42 UTC 2013

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 :|