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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list