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

[Eric Blake]

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.

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

signature.asc
Description: OpenPGP digital signature