From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54442) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFkuP-0005TM-93 for qemu-devel@nongnu.org; Tue, 18 Feb 2014 08:40:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WFkuJ-0006hM-SL for qemu-devel@nongnu.org; Tue, 18 Feb 2014 08:40:25 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48590) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFkuJ-0006h8-Jb for qemu-devel@nongnu.org; Tue, 18 Feb 2014 08:40:19 -0500 Message-ID: <530362B5.8070908@redhat.com> Date: Tue, 18 Feb 2014 06:40:05 -0700 From: Eric Blake MIME-Version: 1.0 References: <1392702802-11592-1-git-send-email-mrhines@linux.vnet.ibm.com> In-Reply-To: <1392702802-11592-1-git-send-email-mrhines@linux.vnet.ibm.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="w8VXv2ikeeT0aJnebrmAQVx8VhB08QNHQ" Subject: Re: [Qemu-devel] [RFC PATCH v1 0/3] provenance: save migration stats after completion to destination List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: mrhines@linux.vnet.ibm.com, qemu-devel@nongnu.org Cc: hinesmr@cn.ibm.com, "Michael R. Hines" , quintela@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --w8VXv2ikeeT0aJnebrmAQVx8VhB08QNHQ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 02/17/2014 10:53 PM, mrhines@linux.vnet.ibm.com wrote: > From: "Michael R. Hines" >=20 > This series allows us to send the contents of the entire MigrationInfo = structure to the > destination once the migration is over. This is very useful for analyzi= ng > the result of a migration, and particularly useful for management softw= are and > policy. Normally, the information ins MigrationInfo is completely lost = when > the source VM is destroyed, but with this series, we can preserve the s= tatistics > for retrieval. >=20 > The QMP architecture has sufficient functionality to serialize and > deserialize arbitrary objects into JSON and back again (very nice). >=20 > We only store the stats from the *last* migration, but not all previous= migrations, > as that could potentially get unwieldy. Thus, it's the management softw= are's (or user's) > responsibility to retrieve the statistics before another migration occu= rs. I like the idea. It seems a little awkward that the final stats are only on the destination, not the source, since it was the source that triggered the migration. But on further thought, migration itself is one-way (destination never sends anything to the source), so destination really is the only point that can see the full picture without making the migration protocol changed to be two-way. Meanwhile, libvirt should be able to cope with it (libvirt does a handshake between source and destination, and does not kill the source until after the destination acknowledges success - so libvirt could query the destination stats, then pass them back over the handshake, so that libvirt could present the final stats from the source even though qemu can't). Now, as to your assertion that serializing the MigrationInfo will always work - I'm not quite sure about that. Let's suppose we add a new field to the struct in qemu 2.1. For back-compat reasons, the new field MUST be marked as optional in the qapi schema. Here are the possibilities: qemu 2.0 -> 2.0: pass the smaller struct from source, expect the smaller struct on dest, no problem qemu 2.0 -> 2.1: pass the smaller struct from source, dest notices the optional field is missing and copes with no problem qemu 2.1 -> 2.1: pass the larger struct from source, dest handles the larger struct with no problem qemu 2.1 -> 2.0: pass the larger struct from source, but dest is only expecting the smaller struct. The last case is the one I worry about: does your implementation gracefully ignore fields that it was not expecting when reconstituting the MigrationInfo on the dest, or does it error out, losing all information in the process? On the other hand, upstream qemu seldom worries about down-version migrations (we strive hard to make sure 2.0 -> 2.1 works, but aren't too worried if 2.1 -> 2.0 fails) - it tends to be more of a situation that downstream distros provide value added by worrying about down-migration. So my concern about what happens on down-migration is not a show-stopper for your patch idea. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --w8VXv2ikeeT0aJnebrmAQVx8VhB08QNHQ 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 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTA2K1AAoJEKeha0olJ0NqZEMH+gOS8cgurB3SYU8kKbCNu4lZ +5EAv5WIVhu8HM0+GKjsACO1U0p6e/H5X3y0JJy8sLdiWHHiTcXzDctqNrrs8t9c DkT2GfrWPLudv2GRBIgw3kNTDkDX+L4KJ5TlBM0PWeJqSlbVRbXvirk3HDQ2fVJu loPohAQ6f1VYyNqqHyCEi/Jv3sFxT9EliXU11MLo3ttN98Lzk8lL6Ak6IW+ZkBAU oWBT5t7besxOzF2UYxIfAOrv9ZkAla3ob8ZBbuaY5/YjyBp361hpQY//exgYLWfE Lopq1d8/VjtCM4BJkbUkm4nQa8ie3KjH/nh4Kj2KGFL6NZ0OwtolmRqqz/vpcqM= =2jom -----END PGP SIGNATURE----- --w8VXv2ikeeT0aJnebrmAQVx8VhB08QNHQ--