Re: [Xen-devel] [RFC] Enabling live-migrate on HVM on qemu-xen device model

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2012-12-17 at 17:02 +0000, Alex Bligh wrote:
> Ian,
> 
> --On 17 December 2012 12:01:52 +0000 Ian Campbell <Ian.Campbell@xxxxxxxxxx> 
> wrote:
> 
> > It's definitely at least a bug in the documentation -- this isn't a
> > feature which was forgotten about, it was explicitly decided hadn't met
> > the 4.2 deadline and wasn't going to be ready in time to wait for. This
> > should have been documented and in the release notes etc, sorry.
> >
> > We did at least manage to tag it tech preview in
> > http://wiki.xen.org/wiki/Xen_Release_Features which implies that it is
> > not yet fully formed.
> 
> It is indeed tagged as 'tech preview'.
> 
> But given that:
> a) HVM is hardly uncommon
> b) live-migrate is pretty essential
> c) qemu-xen device model is the default next time around and the /only/
>    way you can achieve certain things (e.g. rebaseable snapshots)
> d) the code is already written (at least for -unstable) and the patch is
>    smallish (particularly if the JSON stuff is ignored)

These are all true, but none of them are an argument that this is a bug
fix rather than a feature request.

Our general policy is not to backport features because the risk of
regressions is higher, so feature backports need to be considered more
carefully than a bugfix.

> ... I'd suggest a backport to 4.2.x is a reasonable request.

It's certainly a reasonable request, and I'm not suggesting we shouldn't
consider it. My point is that it needs more careful consideration than a
straight bugfix backport.

For example your list above doesn't include the flip sides which are:
      * Migration of PV guests
      * Migration of HVM Qemu-traditional guests
      * HVM Qemu-xen guests for users who don't care about migration

All of these run the risk of regression. Is this new feature worth that
risk? Obviously you think so, but I'm not so sure.

>  I've had a
> first go at the libxl part and Stefano got their first and volunteered
> to do the qemu bit (if he doesn't have time I can have a go at that too).

It's appreciated but ability and or willingness to do the work is only
one part of the equation.

> If necessary we can guard the code either with a compile time switch or
> (as the wiki page suggested to me) a hypervisor command line switch like
> TMEM and AVX, which if it's not enabled would just error the call in the
> same way libxl does at the moment.

I don't think we should have a compile time switch, we should either
backport this new feature as a fully supported thing or not at all.
Adding conditional features like this simply divides our testing
resource.

A hypervisor switch isn't an option because the hypervisor isn't
involved in this decision at all.

Ian.


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