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?  Is there any need for an
> event telling libvirt that enough pre-copy has occurred to make a
> postcopy worthwhile?  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).
> 
> 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.

That's implemented in the v2 I just posted.

Dave

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