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

[Dr. David Alan Gilbert]

* 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.

But auto-throttling is handled automatically by qemu rather than management;
and it seems right that it should be a configurable threshold.

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

Hmm, the way the setup at the moment is setup the new-version would have
had to start the VMs down the one way street, I'm not sure what the old
software would do bad to it.

Having said that, I can see some advantages - in particular knowing when
it's safe to cancel.

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