Re: [Xen-devel] [Planning for Xen-4.6] Migration v2

[Hongyang Yang <yanghy@xxxxxxxxxxxxxx>]

å 11/26/2014 03:54 AM, Andrew Cooper åé:
> Hello,
>
> The purpose of this email is to plan how to progress the migrationv2
> series through to being merged.  I believe I have CC'd everyone with a
> specific interest in this area, but apologies if I have missed anyone.
>
> Migration v2 is in exclusive use in XenServer 6.5.  We primarily
> developed migration v2 because we needed a 32bit -> 64bit toolstack
> upgrade path.  The code has all the features XenServer previously
> supported, and we consider it fully baked and without any known bugs,
> including transparent legacy-to-v2 conversion on upgrade.
>
> We did endeavour to get migration v2 into Xen 4.5, but regrettably this
> did not happen.  A consequence of this, along with the code being in
> XenServer 6.5, is that the wire format is now set in stone.  Luckily, it
> has been explicitly designed to be easy to extend in a forward
> compatible manor, so this is not a problem moving forward.
>
> The expectation is that the migration v2 code will completely replace
> the existing migration code, which will involve removing
> xc_domain_save.c and xc_domain_restore.c, as well as assorted other
> orphaned code in libxenctrl and libxenguest
>
> There are 3 areas of concern which have been identified so far.
>
> 1) TMEM support
>
> Migration v2 doesn't currently have any tmem migration support.  The
> maintainers have been asked whether they actually expect legacy tmem
> migration to work, but I have not heard any reply yet.  At the very
> least, migration v2 tmem support would want some new thought put into
> wire protocol.  I am hoping that, as TMEM is still tech preview and
> still in the process of having XSA-15 fixed, working tmem migration v2
> is not insisted as a prerequisite.
>
> 2) Remus/COLO support
>
> Migration v2 doesn't currently have any Remus support.  There was a
> draft series which added Remus support, and showed that it was
> particularly simple to add Remus support to migration v2.  I integrated
> several bugfixes as a side effect of that series, but the actual Remus
> content needed a refresh.  This got delayed behind the Remus libxl
> effort.  It is my hope that the Remus maintainers can refresh that
> series and provide assistance while testing.
Sure, I'm planning to refresh the patches as soon as Xen 4.6 merge window
opened. And also going to start the work on libxl side because libxl part
of migration v2 has already done(although not fullly finished?). And we
hope COLO support will go into Xen 4.6 also.

> 3) Libxl and xl support
>
> Libxl and xl have as many problems as the libxc code did when it comes
> to incompatible wire formats and layering violations.  In particular, it
> is not possible to determine the bitness of the sending
> libxl-saverestore-helper, meaning that legacy conversion requires active
> administrator input, or at least a passive assumption that the bitness
> is the same.
>
> There is an xl/libxl part of the migration v2 series which attempts to
> rectify this all in one go, as there is no alternative way of doing so.
> The libxl section of the series is certainly not yet complete, but
> specific queries to the maintainers have thusfar gone unanswered.  On
> the other hand, the series does basically WorkForMe, including
> transparent legacy upgrade, suggesting that it is at least in an
> appropriate ballpark.
>
>
> *) Specific non-requirements:
>
> There have been issues identified with dynamic (in a p2m sense) guests
> and migration, which results in failed migration or image corruption.
> While these issues certainly want fixing, they are bugs which exist in
> the legacy code.  As such, they are not prerequisites to fix before v2
> can be accepted.
>
>
> Anyway, it is my hope that this planning email can help get things on
> track to start perusing active development again as soon as the 4.6 dev
> window opens again, with the aim to get all the code merged as early as
> possible in the dev window to allow as much testing as possible.
>
> ~Andrew
>
> .
--
Thanks,
Yang.

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