On 02/17/2014 10:53 PM, mrhi...@linux.vnet.ibm.com wrote: > From: "Michael R. Hines" <mrhi...@us.ibm.com> > > 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 analyzing > the result of a migration, and particularly useful for management software and > policy. Normally, the information ins MigrationInfo is completely lost when > the source VM is destroyed, but with this series, we can preserve the > statistics > for retrieval. > > The QMP architecture has sufficient functionality to serialize and > deserialize arbitrary objects into JSON and back again (very nice). > > 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 software's > (or user's) > responsibility to retrieve the statistics before another migration occurs.
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. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
