WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: 'Pasi Kärkkäinen' <pasik@xxxxxx>, Dave Scott <Dave.Scott@xxxxxxxxxxxxx>
Subject: RE: [Xen-API] Re: [Xen-devel] release of 'xapi' toolstack
From: Jonathan Ludlam <Jonathan.Ludlam@xxxxxxxxxxxxx>
Date: Wed, 4 Nov 2009 15:23:53 +0000
Accept-language: en-US
Acceptlanguage: en-US
Cc: 'Mark Johnson' <johnson.nh@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Julian Chesterfield <Julian.Chesterfield@xxxxxxxxxxxxx>, "xen-api@xxxxxxxxxxxxxxxxxxx" <xen-api@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 04 Nov 2009 07:23:58 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20091103195102.GF1434@xxxxxxxxxxx>
List-help: <mailto:xen-api-request@lists.xensource.com?subject=help>
List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>
List-post: <mailto:xen-api@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=unsubscribe>
References: <81A73678E76EA642801C8F2E4823AD2143B74F148F@xxxxxxxxxxxxxxxxxxxxxxxxx> <521a4d120911030807v33b0e495j26364f55f5680609@xxxxxxxxxxxxxx> <81A73678E76EA642801C8F2E4823AD2143B74F1493@xxxxxxxxxxxxxxxxxxxxxxxxx> <521a4d120911030956n399938cdh59fd5330d34084b1@xxxxxxxxxxxxxx> <81A73678E76EA642801C8F2E4823AD2143B74F1498@xxxxxxxxxxxxxxxxxxxxxxxxx> <20091103195102.GF1434@xxxxxxxxxxx>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcpdX7DCr5g+Q4bgS3yJl2O+bvwO5wAADPoA
Thread-topic: [Xen-API] Re: [Xen-devel] release of 'xapi' toolstack
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.

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.

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-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api