On Thu, Mar 10, 2011 at 07:53:58PM -0700, Jim Fehlig wrote:
> Jim Fehlig wrote:
> > Daniel Veillard wrote:
> >> Sure the URI is a very minimal
> >> part compared to the actual XML description and code but the fact we are
> >> using a different driver internally could possibly be masked to the user.
> >>
> >> Can we make an attempt at hiding how we connect to Xen here like we
> >> did with the "unified" driver but while keeping with different
> >> subdirectories and drivers.
> >>
> >
> > I'm experimenting with an idea that seems to be quite fruitful. In
> > daemon/libvirtd.c, I moved the registration of libxl driver before qemu
> > to prevent qemu from being default if libxenlight is available but xend
> > is not. And in startup of libxl driver, I try to connect to xen:/// URI
> > (legacy toolstack will be tried first) and silently disable the driver
> > if successful.
> >
> > I've tested this approach with xend disabled, which essentially disables
> > xen_unified, and libxl driver is selected by default and when specifying
> > xen:///.
>
> Hmm, not so fast. I had tested this case with '--without-xen' configure
> option. Of course it will work when there is no xen_unified.
>
> > With xend enabled, libxl driver is not loaded and xen_unified
> > is selected by default and when using xen:///.
>
> This still works as expected after building xen_unified.
>
> Perhaps it would be best to simply see if xend is running in the libxl
> startup function. If so, xen_unified is in control, otherwise activate
> the libxl driver. Ideas?
Let's see, our goals really are:
- try to keep the stack above libvirt as unchanged as possible
- allow to test the new driver with xen 4.1
- allow users with 4.1 to still use the old stack since the driver
if far more complete than the new one
It seems to me using xend avalability to direct xen:/// to the old
driver if present and the new one if absent fits the bill. How we
actually manage this may be a bit tricky, but we can use the order of
the drivers to try to do this, and I'm not against doing something
a bit dirty in libvirt to preserve the code and behaviour of existing
applications.
I'm sure we can get this through, and get something which works
well in all situations for 0.9.0 at the end of the mond :-)
thanks !
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list