* Paolo Bonzini (pbonz...@redhat.com) 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.
Dave
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
