Re: [Xen-devel] [libvirt] libxl drivers for libvirt?

["Daniel P. Berrange" <berrange@xxxxxxxxxx>]

On Mon, Oct 29, 2012 at 09:55:28AM -0600, Jim Fehlig wrote:
> Ian Campbell wrote:
> > On Fri, 2012-10-26 at 14:03 +0100, George Dunlap wrote:
> >   
> >> On 24/10/12 19:11, Jim Fehlig wrote:
> >>     
> >>>> * What kind of Xen support for libxl is in the libvirt development
> >>>> branch, and do you have an idea when full support for 4.2 (at least,
> >>>> including migration, suspend/resume, &c) might be available?
> >>>>         
> >>> Nothing has changed in git master over what is available in 0.10.2, but
> >>> we are now starting to pick up this work.  Our priorities are to first
> >>> get the libxl driver compiling against 4.2 and all of the existing
> >>> functionality that works with 4.1 working with 4.2, followed by closing
> >>> the feature gap with the legacy xen driver, and finally closing the
> >>> feature gap with the qemu driver where it makes sense.  This is
> >>> obviously quite a bit of work and any help would be appreciated :).
> >>>
> >>> BTW, we don't have any motivation to add features to the 4.1 version of
> >>> the libvirt libxl driver.
> >>>       
> >> That sounds like a good plan.  For 4.1, xend is still the default 
> >> toolstack, and libxl is a "tech preview"; for 4.2, xl is the default 
> >> toolstack, and (if I understand correctly) we're officially going to be 
> >> supporting the libxl interface in a backwards-compatible way from here 
> >> forward.
> >>
> >> It seems to me that if you have trouble supporting both libxl 4.2 and 
> >> libxl 4.1, that it might be better just to drop 4.1 support and focus on 
> >> 4.2.  Ian Campbell / Jackson: Thoughts?
> >>     
> 
> CC'ing libvirt community to get their input.
> 
> >
> > That's what I would do if I were them ;-)
> >   
> 
> I tend to agree that this might be the best approach.  The libxl in Xen
> 4.1 is essentially a one-off and I question whether we should pollute
> the libvirt libxl driver code with support for a dead, tech preview
> interface.  Xend is still the primary toolstack in Xen 4.1.x, and
> libvirt has a stable, functional driver for this toolstack that can
> (should) be used in Xen 4.1.x deployments.
> 
> Is anyone using the libvirt libxl driver with Xen 4.1 for anything other
> than development or experimentation?
> 
> > Another option would be to fork into 4.1 and 4.2+ versions and to stop
> > adding new stuff to the 4.1 copy. That has its own downsides though.
> >   
> 
> I'd like to hear what the libvirt community thinks about only supporting
> Xen >= 4.2 in the libxl driver.

Given that libxl was "tech preview" in Xen 4.1, I'm fine with any
proposal to have libvirt libxl only work with Xen 4.2, if that's
what you feel is the most appropriate plan. You're the primary
maintainer if this libvirt driver, so I'll defer to your technical
knowledge here on the supportability issues here.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

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