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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel