Daniel Veillard wrote: > 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. > Sorry for the delay. I've been swamped with other tasks and haven't had much time to devout to the driver the past days. I'm now testing the following changes: - In daemon/libvirtd.c, move the registration of libxl driver before qemu to prevent qemu from being default if libxenlight is available but xend is not. - In src/libxl/libxl_driver.c libxlStartup(), try to connect to xen:/// URI. If successful, xen-unified found legacy toolstack so disable libxl driver. Otherwise start the stateful libxl driver. - In src/libxl/libxl_driver.c libxlOpen(), accept xen:/// or libxl:/// URIs. - In src/xen/xen_unified.c xenUnifiedOpen(), try to connect to libxl:/// URI. If successful, libxl driver has been initialized (implies xend is not running) so DECLINE connection and defer to libxl driver. Otherwise handle connection as usual. In my limited testing thus far, this approach seems to be working. The basic assumption here is that xen-unified is tried before libxl, and libxl accepts xen:/// and libxl:/// URIs. If xend is running, then libxl driver will not load and connections to libxl:/// will fail. Connections to xen:/// will be handled by xen-unified as usual. If xend is not running, libxl will load and handle connections on libxl:///. It will also handle connections on xen:/// since xen-unified will see libxl is loaded and return DECLINED instead of ERROR. I'll need to do a lot more testing to see if this approach is plausible, e.g. different configure options (--without-xen vs --without-libxl), remote vs. local, etc. Does anyone see any glaring problems with this approach? If not, and my testing goes well, I'll post a V6 incorporating this approach, along with Daniel's other comments, in the next day or so. Regards, Jim -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list