Re: [Xen-devel] [PATCH v9 15/15] tools/libxc: Migration v2 compatibility for unmodified libxl

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 15/04/15 12:51, Ian Campbell wrote:
> On Fri, 2015-04-10 at 18:16 +0100, Andrew Cooper wrote:
>> These changes cause migration v2 to behave similarly enough to legacy
>> migration to function for HVM guests under an unmodified xl/libxl.
>>
>> The migration v2 work for libxl will fix the layering issues with the
>> toolstack and qemu records, at which point this patch will be unneeded.
>>
>> It is however included here for people wishing to experiment with migration 
>> v2
>> ahead of the libxl work.
> I think it's ultimately up to Wei as RM but I'd be in favour of actually
> enabling this now, i.e. behaving as if XG_MIGRATION_V2 were set by
> default and removing all the old stuff.
>
> Any idea if this is a sufficient compat layer for the existing remus
> functionality?

If this were to be enabled by default, remus would break.  (Also, I
wanted to offer a way for it to be very easily tested without flipping
the big switch right now, in case there was something I missed)

There was a remus/migration v2 series posted ages, but no followup to
first round review because I believe the guys were busy trying to get
remus/libxl in at the same time.

>  
>> +#ifdef XG_LIBXL_HVM_COMPAT
>> +static int dump_qemu(struct xc_sr_context *ctx)
> dump_ made me thing this was going the other way (i.e. saving it), could
> you s/dump/handle/ please? I think that matches the prevailing naming
> scheme better

Ok.  The dump_ name was inherited from the legacy code, then hidden in
an #if 0 for a large part of development.

~Andrew

>
> Apart from that last one:
> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
>
> Ian.
>


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