From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54314) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFx5V-0006Jb-Uj for qemu-devel@nongnu.org; Tue, 18 Feb 2014 21:40:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WFx5P-0002Rk-H1 for qemu-devel@nongnu.org; Tue, 18 Feb 2014 21:40:41 -0500 Received: from mx1.redhat.com ([209.132.183.28]:1311) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFx5P-0002RI-5Y for qemu-devel@nongnu.org; Tue, 18 Feb 2014 21:40:35 -0500 Message-ID: <5304199C.7010901@redhat.com> Date: Tue, 18 Feb 2014 19:40:28 -0700 From: Eric Blake MIME-Version: 1.0 References: <1392702802-11592-1-git-send-email-mrhines@linux.vnet.ibm.com> <530362B5.8070908@redhat.com> <53041734.1080801@linux.vnet.ibm.com> In-Reply-To: <53041734.1080801@linux.vnet.ibm.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KRlqQ4C0XQdOWAgx5MNDUCbUM9R3EgXO7" 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: "Michael R. Hines" , 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) --KRlqQ4C0XQdOWAgx5MNDUCbUM9R3EgXO7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 02/18/2014 07:30 PM, Michael R. Hines wrote: >> qemu 2.0 -> 2.0: pass the smaller struct from source, expect the small= er >> 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 t= oo >> 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-migratio= n. >> So my concern about what happens on down-migration is not a >> show-stopper for your patch idea. >> >=20 > Excellent question! I had not even considered that. I think this > could be solved with QObject arcitecture: So when the statistics > are received by the destination and deserialized, the conversion > from JSON to QObject would need to check to see if the struct > has all the expected fields, and if those fields are not there then > do not "bomb" or anything. Expected fields being present is not the problem. As I said above, as long as we are careful to make all future additions to MigrationInfo be marked optional, then the field can be missing from an older source, and a newer destination will handle the missing fields just fine. The only problem is extra fields. If a newer source sends to an older destination, the software will either die because of unexpected fields, or it will silently ignore the unexpected fields. Normally in QObject, we want to die on unexpected fields (QMP should be up-front and tell users that they are passing in too much stuff) - but this case is the exception to the rule, and we want to ignore the extra stuff. That's where you'll probably have to patch something up; I'm also not sure whether you should expose your actual migrate-set-last-info as a QMP command, or if you instead just do it internally as part of the migration stream but never let QMP modify it. Doing it internally only, and not via QMP, will make it easier to stick to the rule of thumb that QMP should reject unknown dictionary members while your internal version silently ignores them. And again, this only matters for downgrades, where upstream is already less concerned if it doesn't work. >=20 > A deeper question would be: Let's assume a migrate to a lower > version, as in your example: Should the QMP statistics also include > the version of of the source QEMU that the guest originated from? > I could easily modify the patch to include that value....... Not necessary. Upgrades will already work without a version field, as long as all new fields are marked optional. And management apps can already figure out the qemu version of both source and destination qemu outside of the migration stats, so that sticking redundant version information into MigrationInfo just becomes bloat. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --KRlqQ4C0XQdOWAgx5MNDUCbUM9R3EgXO7 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/ iQEcBAEBCAAGBQJTBBmcAAoJEKeha0olJ0NqGycH/2vJljldzaObyCoE4t2ZbIKx hmy+cEcwACTgc20DTp2572XV3yit54c38P5e5E+sYc/TpdM1FOpJAwpdg6gkuJtx vgXbgYko9wvTiW5Jf5ecNjSDiljUkr57QM2Sj8OcibDOYa8K2UuliQSNUjqJbylh tPtgd8kW6U1bqcyREosQKAj2JHXxFV2fqMs5p93Ou7GQnwD9Cl2V9ctUb2HgN88U uAx+ITIaVMvHY0i0XIZm/5vfiuI3080eKV8z0E057u26Pna26SDI+GuYCWPcsGZa Wk/8T9hEzuaIsdL+ZSGj9tJYcTIGC5zqi8Sfr/cQd6NFyw1gfbWXWiLHAWp75c8= =048M -----END PGP SIGNATURE----- --KRlqQ4C0XQdOWAgx5MNDUCbUM9R3EgXO7--