Re: [PATCH v5 0/14] Migration Stream v2

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

On 12/06/14 14:49, Wei Liu wrote:
> On Thu, Jun 12, 2014 at 02:27:39PM +0100, Andrew Cooper wrote:
>> On 12/06/14 04:17, Hongyang Yang wrote:
>>> Hi, Andrew,
>>>
>>> On 06/12/2014 02:14 AM, Andrew Cooper wrote:
>>>> Hello,
>>>>
>>>> Presented here for review is v5 of the Migration Stream v2 work.
>>>>
>>>> Major work in v5 is the legacy conversion python script which is
>>>> capable of
>>>> converting from legacy to v2 format on the fly.  It was tested using
>>>> live
>>>> migration saving in the legacy format, piping through the script and
>>>> restoring
>>>> using the v2 code.
>>>>
>>>> Other work includes a substantial refactoring of the code structure,
>>>> allowing
>>>> for a single generic save() and restore() functions, with function
>>>> pointer
>>>> hooks for each type of guest to implement.  The spec has been updated to
>>>> include PV MSRs in the migration stream.
>>>>
>>>>
>>>> This series depends on several prerequisite fixes which have recently
>>>> been
>>>> committed into staging (and have not passed the push gate at the time of
>>>> writing).  The series also depends on the VM Generation ID series
>>>> from David.
>>>>
>>>> I now consider the core of the v2 code stable.  I do not expect it to
>>>> change
>>>> much too much, other than the identified TODOs (and code review of
>>>> course).
>>>>
>>>>
>>>> The next area of work is the libxl integration, which will seek to
>>>> undo the
>>>> current layering violations.  It will involve introducing a new libxl
>>>> framing
>>>> format (which will happen to look curiously similar to the libxc framing
>>>> format), as well as providing legacy compatibility using the legacy
>>>> conversion
>>>> scripts so migrations from older libxl/libxc toolstacks will continue
>>>> to work.
>>> What are your plans for libxl integration, do you have any design
>>> specs or is
>>> it already implemented in the early stage?
>>
>> There is no code in place yet, and my first course of action is to
>> design how this is going to look.
>>
>> It is going to be conceptually similar, with libxl gaining a framing
>> format.  I also need to coordinate with Wei and his JSON series which is
>> moving data from xl to libxl.  There will be "save libxl v2", "restore
>> libxl v2" and "automatically convert old libxl to new libxl" which will
>> mostly involve the legacy conversion script.
>>
> AIUI you're going to use both the new JSON infrastructure and the
> configuration synchronisation bits, right? I shall upstream the rest of
> my JSON infrastructure when xen-unstable is unblocked, but the
> synchronisation bits will take longer.
>
> Wei.

I care about which (hopefully singular) legacy libxl migration format
needs to be converted, and what the new stream is going to look like.

>From my understanding (without any of your changes in place) the old
"libxl" stream has:

* xl header
   - contains "last boot .cfg file"
* 'libxl bits' which are passed straight to libxc


At a guess, the new stream wants to look something like:

* xl header
* libxl header
* libxl json "current configuration"
* libxc bits
* libxl xenstore key-value pairs record
* qemu record

where the legacy conversion script will have to deal with reframing the
old libxc bits in terms of the new libxl stream.

~Andrew