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.
>
Ok.
> 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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home