From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53478) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sc1Rj-0007t5-K8 for qemu-devel@nongnu.org; Tue, 05 Jun 2012 17:37:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sc1Rh-0003LZ-Mg for qemu-devel@nongnu.org; Tue, 05 Jun 2012 17:37:47 -0400 Received: from mail-pb0-f45.google.com ([209.85.160.45]:44481) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sc1Rh-0003LF-Ga for qemu-devel@nongnu.org; Tue, 05 Jun 2012 17:37:45 -0400 Received: by pbbro12 with SMTP id ro12so8687415pbb.4 for ; Tue, 05 Jun 2012 14:37:43 -0700 (PDT) Message-ID: <4FCE7C21.6040108@codemonkey.ws> Date: Wed, 06 Jun 2012 05:37:37 +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> <4FCE0BBA.2010807@redhat.com> In-Reply-To: <4FCE0BBA.2010807@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: Eric Blake Cc: Yonit Halperin , aliguori@us.ibm.com, alevy@redhat.com, Gerd Hoffmann , qemu-devel@nongnu.org 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 >> >> >> >