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 ?
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).
Regards,
Daniel