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

Tue Sep 24 12:36:23 UTC 2013

On Tue, Sep 24, 2013 at 13:09:42 +0100, Daniel Berrange wrote:
> 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.

Right. The current implementation is not perfect since we make up the
CPU configuration without considering what qemu/kvm can actually provide
but that will change.

I'm still thinking that we should also make sure the CPU stays always
the same once the domain was started to make sure the ABI doesn't
change. But that's not how it works now and will need upstream
discussion first. The end result would be indeed similar to "copy host
CPU configuration" but smarter since it would actually talk to qemu when
creating the CPU model to make sure it only contains features that can
really be provided to a guest.

Jirka