From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Fehlig Subject: Re: [libvirt] [RFC] libxenlight driver Date: Fri, 21 Jan 2011 08:48:10 -0700 Message-ID: <4D39AABA.8090101@novell.com> References: <4D38CA05.2070601@novell.com> <20110121111343.GE11539@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20110121111343.GE11539@redhat.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Daniel P. Berrange" Cc: LibVir , xen-devel List-Id: xen-devel@lists.xenproject.org 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