Re: [Xen-devel] [PATCH v6 0/13] Migration Stream v2

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 09/07/14 16:27, Konrad Rzeszutek Wilk wrote:
> On Wed, Jul 09, 2014 at 10:40:44AM +0100, Andrew Cooper wrote:
>> On 09/07/14 07:01, Hongyang Yang wrote:
>>> Hi Andrew,
>>>
>>> On 07/09/2014 01:35 AM, Andrew Cooper wrote:
>>>> On 08/07/14 17:35, Konrad Rzeszutek Wilk wrote:
>>>>> On Mon, Jul 07, 2014 at 06:37:49PM +0100, Andrew Cooper wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Presented here for review is v6 of the Migration Stream v2 work.
>>>>>>
>>>>>> v6 follows the integration of this code into XenServer, and having
>>>>>> the full
>>>>>> suite of XenRT tests being run.  Included in these tests are live
>>>>>> migrations
>>>>>> from 32bit toolstacks to 64bit toolstacks, using the python
>>>>>> conversion script.
>>>>>> Several corruption issues have been located and fixed, as well as
>>>>>> many minor
>>>>>> improvements.
>>>>>>
>>>>>> In addition, performance tests have been performed.  After finding
>>>>>> an initial
>>>>>> regression, the code uas been tweaked to use writev() in preference to
>>>>>> write() which vastly reduces the number of system calls performed. 
>>>>>> The
>>>>>> performance is now better than the legacy code for all sizes of VM.
>>>>> Fantastic!
>>>>>
>>>>> .. snip..
>>>>>> The code is presented here for comment/query/critism.
>>>>> My notes say: 'tmem and remus need work'. Is that addressed by this
>>>>> patchset or would that be further work?
>>>>>
>>>>> Thank you.
>>>> tmem still completely outstanding.
>>>>
>>>> remus is being worked on by Yang (which is fantastic from my point of
>>>> view).  I believe this is a PoC apparently working?
>>> Do you mean a PoC of remus support on migration v2? If so, yes, I will
>>> post a RFC patch on this.
>>>
>>> BTW, will migration v2 be in Xen 4.5(both libxc and libxl side)?
>>> If it will be in Xen 4.5, will legacy migration be completely removed
>>> from 4.5 or both versions of migration will co-exist for a period?
>> The two versions coexist in my dev branches alone, for debug and
>> development ease.  The plan is not to have two versions at the point at
>> which the code gets committed.
>>
>> As for acceptance, that is a little out of my hands.  I think the libxc
>> side is mostly ready (subject to ripping out the old code and
>> infrastructure), but committing it as-is will break libxl.  (Well - I
>> suppose technically not, given the switch on the environment variable,
>> but it has been indicated in the past that this hack is not going to be
>> committed)
>>
>> As for the libxl side of things, that's going slowly.  As Wei is
>> finding, there is quite a few bits which are currently in xl which need
>> to be in libxl.
> There are two months left before the feature freeze window.
>
> It sounds to me that the 'libxc' parts, remus, tmem will be all
> nicely baked.

Nothing has been started on tmem, and from my point of view I am
focusing on getting the libxl stuff in shape.  One issue with the
current tmem save/restore is that the libxc functions expect to get
control of the fd, which doesn't fit with the new type/length/content
layout.

>
> The 'libxl' is the one that is on the danger side. Do you have thoughts
> of what those 'few bits' are that could be identified?

Still investigating.  I am trying to look for the minimal fixes required
to get libxl working, without interfering with Wei's work to move the
.cfg data to json which also involves moving bits between xl and libxl.

~Andrew

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