From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57068) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sbtxb-0005Up-4Q for qemu-devel@nongnu.org; Tue, 05 Jun 2012 09:38:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SbtxY-0004af-TL for qemu-devel@nongnu.org; Tue, 05 Jun 2012 09:38:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:65301) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SbtxY-0004a5-KZ for qemu-devel@nongnu.org; Tue, 05 Jun 2012 09:38:08 -0400 Message-ID: <4FCE0BBA.2010807@redhat.com> Date: Tue, 05 Jun 2012 07:38:02 -0600 From: Eric Blake MIME-Version: 1.0 References: <1338875386-21051-1-git-send-email-yhalperi@redhat.com> <4FCDF49E.6090006@codemonkey.ws> <4FCE067E.5030903@redhat.com> In-Reply-To: <4FCE067E.5030903@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig7DEC03E2194B2B84DEC1020B" 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: Gerd Hoffmann Cc: Yonit Halperin , aliguori@us.ibm.com, alevy@redhat.com, qemu-devel@nongnu.org, Anthony Liguori This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7DEC03E2194B2B84DEC1020B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 06/05/2012 07:15 AM, Gerd Hoffmann wrote: > Hi, >=20 >> 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? >=20 > Option (1): Wait until spice-server is done before signaling completion= > to libvirt. This is what this patch series implements. >=20 > Advantage is that it is completely transparent for libvirt, thats why I= > like it. >=20 > 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. >=20 > 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. >=20 > Option (2): Add a new QMP event which is emmitted when spice-server is > done, then make libvirt wait for it before killing qemu. >=20 > 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. >=20 > Option (3): Your suggestion? >=20 > thanks, > Gerd >=20 >=20 >=20 --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig7DEC03E2194B2B84DEC1020B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJPzgu7AAoJEKeha0olJ0Nql18H/0+DOzjNlG1x765b8rdu3wEt KpxNWNhloqtX6L5o1NEoZWV3YDG+eVTWGQO8Vas64FNrKVQHWnsdIBw207R8IaXQ RKt0srnJHgIDqlXRiBnS0VbMC9yKJMVQ+C7VKjyelUtKOpG+F+KN/rOivVXYKT8u OMbB0nfwOaqyERfYWOZ3TS4xaaM+H46gMKR330pK5B1IoyOMUDcKGrII26dyVTrz WlQ9EO8AB2Xi0Iq9Ic4gYOIVAWTzNj0I1/RnxZgoFvg+9TNjaeUBgbQay4IvRihE qKCegx96TJrB29BKVihwg2FbaQMBQtoM3o/2/gMWm9/72TetKEzoKJxnQveMFw8= =6ca7 -----END PGP SIGNATURE----- --------------enig7DEC03E2194B2B84DEC1020B--