Re: [PATCH 00/27] Libxl migration v2

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 17/06/15 02:55, Wen Congyang wrote:
> On 06/15/2015 09:44 PM, Andrew Cooper wrote:
>> This series adds support for the libxl migration v2 stream, and untangles the
>> existing layering violations of the toolstack and qemu records.
>>
>> At the end of the series, legacy migration is no longer used.
>>
>> Note: Remus support is broken and (RFC) fixed in separate patches in this
>> series.  It was too tangled to fix in a bisectable fashon.  Plain
>> suspend/migrate/resume however is (should be) bisectable along the entire
>> series.
>>
>> There are a couple of outstanding questions:
>>
>> 1) What to do about the toolstack/xenstore record.  It is currently by being
>>    passed around as a blob, but it might be better to split it out.
>>
>> 2) What (if any) ABI/API qualifications are needed? (Particularly in reference
>>    to patch 21)
>>
>> The Remus code is untested by me, but is hopefully in the correct ballpark.
>> All other combinations of suspend/migrate/resume have been tested with PV and
>> HVM guests (qemu-trad and qemu-upstream), including 32 -> 64 bit migration
>> (which was the underlying bug causing us to write migration v2 in the first
>> place).
>>
>> There are some further improvements which could be made.  In particular, it
>> appears that sending the toolstack record on each checkpoint is redundant, and
>> there is certainly room for some more pruning of the legacy migration code.
> Do you mean: libxl__toolstack_save is harmless, and it can be called when the
> guest is running?
>
> Thanks
> Wen Congyang

It is harmless when a guest is running.

It contains the contents of the device models "/physmap" xenstore tree,
which is empty for a PV or qemu-trad HVM guest and constant-after-setup
for qemu-upstream HVM guests

(I don't see why this information isn't maintained in the Qemu record
itself because nothing else uses it).

~Andrew