Re: [Qemu-devel] [PATCH 00/46] Postcopy implementation

[Dr. David Alan Gilbert]

* Eric Blake (address@hidden) wrote:
> On 07/10/2014 05:29 AM, Dr. David Alan Gilbert wrote:
> > * Paolo Bonzini (address@hidden) wrote:
> >> Il 07/07/2014 16:02, Dr. David Alan Gilbert ha scritto:
> >>>>> Could you have instead a "migrate_start_postcopy" command, and leave the
> >>>>> policy to management instead?
> >>> Hmm; yes that is probably possible - although with the 
> >>> migration_set_parameter
> >>> configuration you get the best of both worlds:
> >>>   1) You can set the parameter to say a few seconds and let QEMU handle it
> >>>   2) You can set the parameter really large, but (I need to check) you 
> >>> could
> >>>      drop the parameter later and then cause it to kick in.
> >>>
> >>> I also did it this way because it was similar to the way the 
> >>> auto-throttling
> >>> mechanism.
> >>
> >> Auto-throttling doesn't let you configure when it kicks in (it doesn't even
> >> need support from the destination side).  For postcopy you would still have
> >> a capability, like auto-throttling, just not the argument.
> >>
> >> The reason why I prefer a manual step from management, is because postcopy
> >> is a one-way street.  Suppose a newer version of management software has
> >> started migration with postcopy configured, and then an older version is
> >> started.  It is probably an invalid thing to do, but the confusion in the
> >> older version could be fatal and it's nice if there's an easy way to 
> >> prevent
> >> it.
> > 
> > Actually the 'migrate_start_postcopy' idea is growing on me; Eric is that
> > also your preferred way of doing it?
> > 
> > If we did this I'd:
> >    1) Remove the migration_set_parameter code I added
> >    2) and the x-postcopy_ram_start_time parameter
> >    3) Add a new command migrate_start_postcopy that just sets a flag
> >       which is tested in the same place as I currently check the timeout.
> >       If it's issued after a migration has finished it doesn't fail because
> >       that would be racy.  If issued before a migration starts that's OK
> >       as long as postcopy is enabled and means to start postcopy mode
> >       immediately.
> 
> So to make sure I understand, the idea is that the management starts
> migration as normal, then after enough time has elapsed, issues a
> migrate_start_postcopy to tell qemu that it is okay to switch to
> postcopy at the next convenient opportunity? 

Yep, that's the idea.

> Is there any need for an
> event telling libvirt that enough pre-copy has occurred to make a
> postcopy worthwhile?

I'm not sure that qemu knows much more than management does at that
point; any such decision you can make based on an arbitrary cut off
(i.e. migration is taking too long) or you could consider something
based on some of the other stats that migration already exposes
(like the dirty pages stats); if we've got any more stats that you
need we can always expose them.

> And of course, I _still_ want an event for when
> normal precopy migration is ready (instead of the current solution of
> libvirt having to poll to track progress).

Agreed; although we can just do that independently of this big patch set.

> But in answer to your question, yes, it sounds like adding a new command
> (actually, per QMP conventions it should probably be
> migrate-start-postcopy with dashes instead of underscore) for management
> to determine if/when to allow postcopy to kick in seems okay.

OK, I'll do it.

Dave

> 
> -- 
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
> 


--
Dr. David Alan Gilbert / address@hidden / Manchester, UK