Re: [Xen-devel] [Patch v4] tools/migrate: Fix regression when migrating from older version of Xen

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2013-07-30 at 15:11 +0100, Andrew Cooper wrote:
> On 30/07/13 10:42, Ian Campbell wrote:
> > On Mon, 2013-07-29 at 18:07 +0100, Andrew Cooper wrote:
> >> Changes since v3:
> >>  * Plumb the xl "remus" flag down through libxl.  This is done by 
> >> introducing
> >>    libxl_domain_create_restore_remus()
> > I don't think we want to expose the name of a particular HA strategy in
> > the libxl API. If we were to add anything then it should be
> > _checkpointed()
> 
> Sure.  That is rather better.
> 
> >  or something however my strong preference would be to
> > add a flags parameter in a backwards compatible way now (perhaps using a
> > similar scheme to Olaf's which I linked to before) rather than to start
> > combinatorially exploding the API for each new variant.
> 
> That is impossible to backport; this is a fix for a regression affecting
> all currently maintained version of Xen
> 
> >
> > Image a new, hypothetical, "pre-migration" mode (contrasted to our
> > current post-migration mode), now we have four API calls required (pre-
> > vs. post-migration crossed with regular vs. checkpointed).
> 
> It isn't nice, but IanJ and I decided that this was the neatest way.

I'm not really convinced that checkpointing was a "supported" feature of
libxl in 4.2/4.3 -- it only supports memory and CPU checkpointing and
not I/O. http://wiki.xen.org/wiki/Xen_Release_Features doesn't really
distinguish the Xend implementation from the libxl one. So we could
decide that 4.2/4.3 don't really support checkpointing in any meaningful
way, other than as a basis for future development, and hardcode
checkpoint == off in the backport.

Alternatively, in 4.4: Use LIBXL_API_VERSION to introduce a flags field
without worrying about backports. Then have:
        #if LIBXL_API_VERSION == 0x040200 || LIBXL_API_VERSION == 0x040300
        #define LIBXL_HAVE_DOMAIN_RESTORE_CHECKPOINTING
        #define libxl_domain_restore_checkpointed(x, y, z) 
libxl_domain_restore(x, y, z, FLAG_CHECKPOINTED)
        #endif

and then in the backports:
        #define LIBXL_HAVE_DOMAIN_RESTORE_CHECKPOINTING
        int libxl_foo_checkpointed(x, y, z);
        
+ implement it in the obvious way.

This way we get backwards compatibility *and* an extensible API going
forward.

> Unless we can agree on a different way of backporting this fix.
> 
> >
> >> + * If this is defined, libxl_domain_create_restore() has had a _remus()
> >> + * varient created to help fix a regression in the migration stream 
> >> format.
> > If you end up reusing any of this text then it should be "variant".
> >
> >
> 
> Ok
> 
> ~Andrew



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