Re: [libvirt] [Xen-devel] Re: [RFC] libxenlight driver
On Fri, 21 Jan 2011, Jim Fehlig wrote:
Daniel P. Berrange wrote:
> On Thu, Jan 20, 2011 at 04:49:25PM -0700, Jim Fehlig wrote:
>
>> I'm looking into creating a driver for the new Xen xl/libxl toolstack
>> (aka libxenlight [1]), set to become the default in upcoming Xen 4.1.0
>> release.
>>
>> My first hurdle is deciding whether this should be a new driver or
>> integrated with existing xen-unified driver. Initially I thought a new
>> driver would be a better approach - a clean break from the old code,
>> similar to the xenapi driver. libxenlight is also stateless (no managed
>> domains), which seems like another good argument for a new driver. But
>> libxenlight is really just another interface into the same hypervisor,
>> so in that regard it should be a xen-unified subdriver.
>>
>
> Something on the system must be stateful, continually monitoring
> guests & taking neccessary actions ? eg If XenD isn't used, then
> what is responsible for restarting guests which crash, or performing
> core dumps on crashed guests, etc, etc ?
>
Good questions. I have just started looking at the new toolstack, and
frankly don't yet know how this is handled. Adding xen-devel for
comment ...
xenstore is stateful and the hypervisor keeps a state of the system so
there is no need for libxenlight to maintain yet another additional
state of the system on top of them: it just relies on the informations
already available through them.
xl (the minimal C toolstack on top of libxenlight) spawns a daemon per
domain to handle domain death events and cdrom events.
I should also mention that one of the design goals of libxenlight is
that no libxenlight users (toolstacks like libvirt) should need to use
anything else but libxenlight to perform Xen operations. So you
shouldn't need to call any xenctrl functions or deal with xenstore
directly.
> This would have a bearing on how best to design a libvirt driver
I don't know much about libvirt but I would write a brand new
libxenlight driver.
>> There are certainly benefits to the xen-unified subdriver
approach, e.g.
>> the existing hypervisor and xenstore subdrivers can be leveraged, the
>> former providing all the capabilities code. But AFAIK, libxenlight and
>> xend should not be used together, so I don't think we would want the
>> xend subdriver activated if libxenlight is detected. Supposedly xl can
>> be used as a direct replacement for xm, allowing unconditional use of
>> that subdriver.
>>
>> BTW, Ian Jackson responded [2] to some of my questions regarding
>> compatibility between old and new toolstack if you are interested.
>>
>> I'd like to hear other's opinions on a new driver vs. a xen-unified
>> subdriver.
>>
>
> Due to the number of revisions of Xen userspace stack, and the
> need to talk to so many pieces to get an efficient driver, the
> current Xen unified driver is rather hairy. Particularly if
> XenD itself is deprecated as a control mechanism, then I'd
> go for a new standalone driver, that runs from libvirtd context
> and leverages the standard libvirt storage/network/inteface
> drivers for non-HV stuff (which I assume libxenlight doesn't
> cover).
>
Correct. AFAICT, libxenlight does not cover any host storage or network
management. A libxenlight driver will be a hypervsisor driver only.
Yep.
Feel free to ask any questions you might have on libxenlight to xen-devel!