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

[Eric Blake]

On 02/18/2014 07:30 PM, Michael R. Hines wrote:

>> 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.
>>
> 
> 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.

> 
> 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.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature