Re: [libvirt] [PATCH V5] Add libxenlight driver

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?