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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

~Andrew

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