Re: [Qemu-devel] [RFC PATCH 0/5] asynchronous migration state change handlers

[Anthony Liguori <anthony@codemonkey.ws>]

On 06/05/2012 09:38 PM, Eric Blake wrote:
> On 06/05/2012 07:15 AM, Gerd Hoffmann wrote:
>>    Hi,
>>
>>> Absolutely not.  This is hideously ugly and affects a bunch of code.
>>>
>>> Spice is *not* getting a hook in migration where it gets to add
>>> arbitrary amounts of downtime to the migration traffic.  That's a
>>> terrible idea.
>>>
>
>> So, the big question is how to tackle the issue?
>>
>> Option (1): Wait until spice-server is done before signaling completion
>> to libvirt.  This is what this patch series implements.
>>
>> Advantage is that it is completely transparent for libvirt, thats why I
>> like it.
>>
>> Disadvantage is that it indeed adds a small delay for the spice-server
>> handshake.  The target qemu doesn't process main loop events while the
>> incoming migration is running, and because of that the spice-server
>> handshake doesn't run in parallel with the final stage of vm migration,
>> which it could in theory.
>>
>> BTW: There will be no "arbitrary amounts of downtime".  Seamless spice
>> client migration is pretty pointless if it doesn't finish within a
>> fraction of a second, so we can go with a very short timeout there.
>>
>> Option (2): Add a new QMP event which is emmitted when spice-server is
>> done, then make libvirt wait for it before killing qemu.
>>
>> Obvious disadvantage is that it requires libvirt changes.
>
> But there was recently a proposal for a new monitor command that will
> let libvirt query which events a given qemu supports, and therefore
> libvirt can at least know in advance whether to expect and wait for the
> event, or to fall back to some other option.  Just because libvirt would
> require a change doesn't necessarily rule out this option.

Right, this approach sounds much, much better to me too because it doesn't 
affect migration downtime.

Regards,

Anthony Liguori

>
>>
>> Option (3): Your suggestion?
>>
>> thanks,
>>    Gerd
>>
>>
>>
>