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

Daniel Veillard wrote: > On Wed, Mar 09, 2011 at 11:45:49PM -0700, Jim Fehlig wrote: > > >> Add a new xen driver based on libxenlight [1], which is the primary >> toolstack starting with Xen 4.1.0. The driver is stateful, runs >> privileged only, and is accessed with libxl:/// URI. >> >> V5: >> - Ensure events are unregistered when domain private data >> is destroyed. Discovered and fixed by Markus Gross. >> >> V4: >> - Handle restart of libvirtd, reconnecting to previously >> started domains >> - Rebased to current master >> - Tested against Xen 4.1 RC7-pre (c/s 22961:c5d121fd35c0) >> >> V3: >> - Reserve vnc port within driver when autoport=yes >> >> V2: >> - Update to Xen 4.1 RC6-pre (c/s 22940:5a4710640f81) >> - Rebased to current master >> - Plug memory leaks found by Stefano Stabellini and valgrind >> - Handle SHUTDOWN_crash domain death event >> >> [1] http://lists.xensource.com/archives/html/xen-devel/2009-11/msg00436.html >> >> > [...] > > > > It's great to have documentation, but ... > I just regret that we are unable to hide how we connect to the Xen > server, after all libvirt was precisely designed to try to minimize > the change on the application stack as the lower layers of > virtualization evolves, and here we fail. > Yes, well said - and I agree. I mentioned this concern early on, but unfortunately it was on IRC instead of the list where it could get more discussion. > 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:///.

With xend enabled, libxl driver is not loaded and xen_unified is selected by default and when using xen:///.