From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56100) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ScF2i-0003BD-Qh for qemu-devel@nongnu.org; Wed, 06 Jun 2012 08:08:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ScF2d-0001yz-Pb for qemu-devel@nongnu.org; Wed, 06 Jun 2012 08:08:52 -0400 Received: from mail-pz0-f45.google.com ([209.85.210.45]:39289) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ScF2d-0001yn-JF for qemu-devel@nongnu.org; Wed, 06 Jun 2012 08:08:47 -0400 Received: by dadv2 with SMTP id v2so9443541dad.4 for ; Wed, 06 Jun 2012 05:08:46 -0700 (PDT) Message-ID: <4FCF4848.9010005@codemonkey.ws> Date: Wed, 06 Jun 2012 20:08:40 +0800 From: Anthony Liguori MIME-Version: 1.0 References: <1338875386-21051-1-git-send-email-yhalperi@redhat.com> <4FCDF49E.6090006@codemonkey.ws> <4FCE067E.5030903@redhat.com> <4FCF1E70.3030703@redhat.com> <4FCF214D.8060001@codemonkey.ws> <4FCF46B0.1010905@redhat.com> In-Reply-To: <4FCF46B0.1010905@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 0/5] asynchronous migration state change handlers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Yonit Halperin Cc: aliguori@us.ibm.com, alevy@redhat.com, Gerd Hoffmann , qemu-devel@nongnu.org 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. > 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 >>>> >>> >> >