From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45252) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTYbQ-0001b6-Te for qemu-devel@nongnu.org; Tue, 08 Oct 2013 10:49:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VTYbM-000548-0U for qemu-devel@nongnu.org; Tue, 08 Oct 2013 10:49:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59779) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTYbL-000541-Ni for qemu-devel@nongnu.org; Tue, 08 Oct 2013 10:49:31 -0400 Message-ID: <52541B75.7010704@redhat.com> Date: Tue, 08 Oct 2013 08:49:25 -0600 From: Eric Blake MIME-Version: 1.0 References: <1374501718-2581-1-git-send-email-mrhines@linux.vnet.ibm.com> <1374501718-2581-8-git-send-email-mrhines@linux.vnet.ibm.com> In-Reply-To: <1374501718-2581-8-git-send-email-mrhines@linux.vnet.ibm.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OtBWBKCQF7H930K4erW5X3FmxfD525MhG" Subject: Re: [Qemu-devel] [PATCH v3 resend 7/8] rdma: introduce MIG_STATE_NONE and change MIG_STATE_SETUP state transition List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: mrhines@linux.vnet.ibm.com Cc: aliguori@us.ibm.com, quintela@redhat.com, qemu-devel@nongnu.org, owasserm@redhat.com, abali@us.ibm.com, mrhines@us.ibm.com, gokul@us.ibm.com, pbonzini@redhat.com, chegu_vinod@hp.com, knoel@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OtBWBKCQF7H930K4erW5X3FmxfD525MhG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 07/22/2013 08:01 AM, mrhines@linux.vnet.ibm.com wrote: > From: "Michael R. Hines" >=20 > As described in the previous patch, until now, the MIG_STATE_SETUP > state was not really a 'formal' state. It has been used as a 'zero' sta= te > (what we're calling 'NONE' here) and QEMU has been unconditionally tran= sitioning > into this state when the QMP migration command was called. Instead we w= ant to > introduce MIG_STATE_NONE, which is our starting state in the state mach= ine, and > then immediately transition into the MIG_STATE_SETUP state when the QMP= migrate > command is issued. >=20 > In order to do this, we must delay the transition into MIG_STATE_ACTIVE= until > later in the migration_thread(). This is done to be able to timestamp t= he amount of > time spent in the SETUP state for proper accounting to the user during > an RDMA migration. >=20 > Furthermore, the management software, until now, has never been aware o= f the > existence of the SETUP state whatsoever. This must change, because, tim= ing of this > state implies that the state actually exists. >=20 > These two patches cannot be separated because the 'query_migrate' QMP > switch statement needs to know how to handle this new state transition.= This patch causes an issue with libvirt migration: https://bugzilla.redhat.com/show_bug.cgi?id=3D1015636 > + case MIG_STATE_SETUP: > + info->has_status =3D true; > + info->status =3D g_strdup("setup"); > + break; You are now returning a state that older libvirt versions are not expecting. Obviously, we can patch newer libvirt to make migration work again, but should we be thinking about damage control by stating that an older management app should still be able to drive migration on a new qemu? Or is it acceptable to state that newer qemu requires newer management tools? If we try to support this working under older management tools, maybe the approach is that we have to add some new migration capability; newer management tools set the capability to true and are therefore allowed to see the new state name; older management tools do not set the capability and when that is the case we guarantee that we do not return a state string that the older tool is not expecting. Thoughts on whether we should pursue this? --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --OtBWBKCQF7H930K4erW5X3FmxfD525MhG 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.14 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJSVBt1AAoJEKeha0olJ0NqBzYH/A4xvTduyzsHWrxhbcVmecC7 hxcxCxxq76hSSeLEBALI74zSbDiy4ZdASDMq5RXuPmXppUxvBDm2HG5hRqDsp2Ap IMThdfv/aWC0xsunaxzw2EA0ZI/G7yNtE5cprYiWcFOYskW8G3NFJpkYtmnue5Sa Yx64tTkfr3Cq2fVA3gydivEMoVALTUjJWKwpBoxg2siaKumLz/SoaD7ijD1rwPLF dMrs79k1AqvOwVRE2NmHDtWxlJRsaXPLsW53zjEJIB+MBnOjOa3SMtphKeB7fF9A ioDCHmRAQ/AUwwFc0Mm5N5Vvx+0CgEu2KpUpuNVwht1oeWQNqetdmgjvqNnK1GA= =qt4y -----END PGP SIGNATURE----- --OtBWBKCQF7H930K4erW5X3FmxfD525MhG--