Re: [libvirt] [RFC] libxenlight driver

[Jim Fehlig <jfehlig@novell.com>]

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 ...

> This would have a bearing on how best to design a libvirt 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.

Regards,
Jim