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

[Alon Levy]

On Wed, Jun 06, 2012 at 08:08:40PM +0800, Anthony Liguori wrote:
> On 06/06/2012 08:01 PM, Yonit Halperin wrote:
> >On 06/06/2012 12:22 PM, Anthony Liguori wrote:
> >>
> >>So send a QMP event and call it a day.
> >>
> >Using a QMP event is making spice seamless migration dependent on libvirt
> >version.
> 
> That is not an acceptable justification.

To let spice know that libvirt doesn't support the new event would
require libvirt capabilities advertisement to qemu. Is that acceptable?

> 
> >Delaying the status change to "migration completed", (1) doesn't affect
> >qemu migration time, the migration has already completed, and (2) will allow
> >spice to seamlessly migrate, no matter which libvirt version is used.
> 
> (1) libvirt starts the destination with -S and starts it manually IIUC.  It
> waits for the migration completed event to do this.
> 
> Seriously, just add the event.  Async notifiers are not an option.
> 
> Regards,
> 
> Anthony Liguori
> 
> >
> >Yonit.
> >>Regards,
> >>
> >>Anthony Liguori
> >>
> >>>
> >>>Yonit.
> >>>
> >>>>
> >>>>Very short version: The requirement is simply to not kill qemu on the
> >>>>source side until the source spice-server has finished session handover
> >>>>to the target spice-server.
> >>>>
> >>>>Long version: spice-client connects automatically to the target
> >>>>machine, so the user ideally doesn't notice that his virtual machine was
> >>>>just migrated over to another host.
> >>>>
> >>>>Today this happens via "switch-host", which is a simple message asking
> >>>>the spice client to connect to the new host.
> >>>>
> >>>>We want move to "seamless migration" model where we don't start over
> >>>>from scratch, but hand over the session from the source to the target.
> >>>>Advantage is that various state cached in spice-client will stay valid
> >>>>and doesn't need to be retransmitted. It also requires a handshake
> >>>>between spice-servers on source and target. libvirt killing qemu on the
> >>>>source host before the handshake is done isn't exactly helpful.
> >>>>
> >>>>[ Side note: In theory this issue exists even today: in case the data
> >>>>pipe to the client is full spice-server will queue up the switch-host
> >>>>message and qemu might be killed before it is sent out. In practice
> >>>>it doesn't happen though because it goes through the low-traffic main
> >>>>channel so the socket buffers usually have enougth space. ]
> >>>>
> >>>>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.
> >>>>
> >>>>Option (3): Your suggestion?
> >>>>
> >>>>thanks,
> >>>>Gerd
> >>>>
> >>>
> >>
> >
> 
>