Jim Fehlig wrote: > 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:///. 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? Thanks, Jim -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list