Hopefully someone can help get multipath working inside a domU. I'm using
Xen 4.2.3 on a SLES 11 dom0, and both a SLES11 domU and a CentOS 6 domU.
I'm using NPIV to connect my SAN disks to my domU, and, due to the way my
SAN presents the LUNs, need to use multipath inside the domU. I've tried
this on both SLES11 and CentOS6 with pretty much the same result. The root
issue seems to be that no "disk identity" (SCSI ID/WWID/etc.) is
passed through from dom0 to domU on the NPIV connection (or any other xenblk
disk connection). The symptom is that scsi_id exits with an error (1) and so
multipath, in its default configuration, won't create the maps for the
multipath devices.
So, I have a couple of ideas, wondering if anyone has ever done either of these
before...
First, perhaps there is a way to manually set up a multipath map, rather than
having the domU try to detect it? Has anyone ever done this? My Google
searches have turned up very little useful info, here - mostly articles about
manually failing over/back a path - which is not what I want. I'm not sure
if the multipath.conf file supports manual multipath maps, but this would be an
acceptable work-around for me, since I'm statically defining the disks that
are being passed through over NPIV, so they're not likely to change much.
Second, and perhaps a little safer, would be to try to create my own multipath
ID script that could look at something unique about the disks and make a
determination. I thought about something like reading in the first X bytes
(partition table) of the disk and doing a sha1sum on them, since that should be
fairly unique for each disk. Does anyone have any ideas on the best way to do
this? Maybe the size of the disk, plus the first 512 bytes or something like
that? I'm open to suggestions on what will be the best guarantee of
uniqueness of disks.
And, yes, I know one way to do this is to just present the LUNs to dom0 and have
dom0 do the multipathing, but, for various reasons, it's better if I can
figure out a way to use NPIV and accomplish this.
Thanks,
Nick
--------
This e-mail may contain SEAKR Engineering (SEAKR) Confidential and Proprietary
Information. If this message is not intended for you, you are strictly
prohibited from using this message, its contents or attachments in any way. If
you have received this message in error, please delete the message from your
mailbox. This e-mail may contain export-controlled material and should be
handled accordingly.
