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