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