[libvirt] [PATCH V5] Add libxenlight driver

[Jim Fehlig]

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