[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |