This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-API] Re: [Xen-devel] release of 'xapi' toolstack

To: Jonathan Ludlam <Jonathan.Ludlam@xxxxxxxxxxxxx>
Subject: Re: [Xen-API] Re: [Xen-devel] release of 'xapi' toolstack
From: Pasi Kärkkäinen <pasik@xxxxxx>
Date: Fri, 6 Nov 2009 11:54:41 +0200
Cc: 'Mark Johnson' <johnson.nh@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Julian Chesterfield <Julian.Chesterfield@xxxxxxxxxxxxx>, Dave Scott <Dave.Scott@xxxxxxxxxxxxx>, "xen-api@xxxxxxxxxxxxxxxxxxx" <xen-api@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 06 Nov 2009 01:55:02 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <B45B24330584FB4AAE78E08B8F5E5B5E42CECCA6FC@xxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <81A73678E76EA642801C8F2E4823AD2143B74F148F@xxxxxxxxxxxxxxxxxxxxxxxxx> <521a4d120911030807v33b0e495j26364f55f5680609@xxxxxxxxxxxxxx> <81A73678E76EA642801C8F2E4823AD2143B74F1493@xxxxxxxxxxxxxxxxxxxxxxxxx> <521a4d120911030956n399938cdh59fd5330d34084b1@xxxxxxxxxxxxxx> <81A73678E76EA642801C8F2E4823AD2143B74F1498@xxxxxxxxxxxxxxxxxxxxxxxxx> <20091103195102.GF1434@xxxxxxxxxxx> <B45B24330584FB4AAE78E08B8F5E5B5E42CECCA6FC@xxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.13 (2006-08-11)
On Wed, Nov 04, 2009 at 03:23:53PM +0000, Jonathan Ludlam wrote:
> Hi Pasi,
> Julian Chesterfield (cc'd) is the person responsible for the storage 
> backends - I'm sure he'll point you in the right direction.


> Anyway, if you're planning on hacking on the multipathing code, 
> there are a couple of things you should probably be aware of - 
> the version of multipathd that we ship differs in some important 
> ways from the stock CentOS one. There are a couple of incidental 
> patches that do things like alert when paths go up/down, but the 
> most important one is the patch that stops multipathd from listening 
> for uevents. The CentOS version has both multipathd listening for 
> uevents and multipath invoked from the udev scripts, which was racy 
> and we found that it was difficult to decide when the process of 
> adding a LUN had completed. What we've done is ensure that everything 
> is done synchronously, so the backends explicitly tell multipathd 
> (through the multipathd cli interface -- which is *not* the same as 
> the command 'multipath'!) when paths arrive and disappear. 
> So when a path appears, we effectively do:
> # echo "add path sd<x>" | multipathd -k
> When this command returns, we know that multipathd has finished 
> processing the device, and the devmapper node has appeared.

Are these patches available from somewhere? 

> The only thing that is done automatically from udev is a failsafe 
> rule that's executed when a device is removed from the system. 
> This rule tells multipathd to forget about the particular path, 
> which prevents a possible condition where LVM waits indefinitely 
> trying to access a multipathed device where all the paths have vanished. 
> This is probably the most important aspect of how multipath works 
> currently - obviously there's some more detail, and we'll have to 
> write this up on the xen.org wiki at some point.

Thanks for the info. This is indeed good to know beforehands :)

-- Pasi

> Cheers,
> Jon
> -----Original Message-----
> From: xen-api-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-api-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Pasi Kärkkäinen
> Sent: 03 November 2009 19:51
> To: Dave Scott
> Cc: 'Mark Johnson'; xen-devel@xxxxxxxxxxxxxxxxxxx; xen-api@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-API] Re: [Xen-devel] release of 'xapi' toolstack
> On Tue, Nov 03, 2009 at 06:35:16PM +0000, Dave Scott wrote:
> > 
> > Mark Johnson wrote:
> > > Other than the GUI, what will remained closed source in the
> > > XenServer product?  i.e. are there any extensions to the cli,
> > > xapi? Any additional libs not present in xen-api-libs.hg?
> > > Any extensions to blktap?
> > 
> > At present a few server-side pieces are not open-source. These are (from 
> > memory):
> > 1. the heartbeat/liveset management daemon which is needed for HA (xapi 
> > talks to this via a simple interface)
> > 2. some 3rd party FC tools
> > 3. a few storage backends (NetApp, EQL and StorageLink)
> > 
> Hmm.. Citrix XenServer doesn't currently support iSCSI multipathing with
> EQL storage. I've understood the EQL storage backend is mostly for other
> features (snapshots, cloning etc), so now I could actually help fix the
> multipathing stuff.. 
> Any pointers where to look for the iSCSI multipathing stuff?
> -- Pasi
> _______________________________________________
> xen-api mailing list
> xen-api@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/mailman/listinfo/xen-api

Xen-devel mailing list