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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 26/11/14 16:50, Ian Campbell wrote:
> On Tue, 2014-11-25 at 19:54 +0000, Andrew Cooper wrote:
>> 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.
> IOW when migrating legacy->new we have the same restriction as we do
> today in the purely legacy world, which is that the two dom0's must
> having match bit widths?

The legacy->new conversion removes bitness from the equation, but the
bitness of the legacy side is an input parameter to conversion.

For XenServer, this is easy, as all older versions of XenServer are
32bit.  This version, and future versions will use the new format, where
bitness is specifically irrelevant.

For xl, this is harder.  There exist both 32 and 64bit versions doing
legacy migration, and on the receiving side it is impossible to
determine, given only the incoming stream.

>
> IMHO this is fine. It essentially means that for xl users there is some
> delayed gratification wrt the promise of migration between non-alike
> dom0s. The migration from 4.5(legacy)->4.6(v2) won't support such
> migrations, but the next step from 4.6(v2)->4.7(v2) will.

Two options exist.

1) Assume that the sending bitness is the same as the receiving
bitness.  This is already the status quo, and will require that the two
dom0s are the same width.

2) Allow the administrator to specify the bitness of the sending side. 
In this case, xl 4.5(legacy)->4.6(v2) works even cross-bitness.

~Andrew


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