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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home