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

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.