Re: [Qemu-devel] [RFC PATCH v1 0/3] provenance: save migration stats after completion to destination

[Eric Blake]

On 02/17/2014 10:53 PM, address@hidden wrote:
> From: "Michael R. Hines" <address@hidden>
> 
> 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