[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

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


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.