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

[Ian Campbell <ian.campbell@citrix.com>]

On Wed, 2015-04-15 at 13:14 +0100, Andrew Cooper wrote:
> 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.

Lets add those guys to the CC list then. It looks like they were on the
"Migration v2 and related work for 4.6" thread so this should come as no
surprise.

> >> +#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@citrix.com>
> >
> > Ian.
> >
>