Thanks Malahal, you just put me in a "Ok, that's my 'dumb guy' moment for the day." I added "#!/bin/bash" as the first line of my /sbin/xpdisk script, and then modified the script to just spit out the CU:LDev info from the HP-supplied-but-not-supported xpinfo command, and now it looks like it's working: ===== path info sda (mask 0x1f) ===== bus = 1 dev_t = 8:0 size = 28452960 vendor = HP product = OPEN-E rev = 2114 h:b:t:l = 1:0:0:0 tgt_node_name = 0x50060e80039c5a04 serial = 40026 path checker = readsector0 (internal default) state = 2 getprio = /bin/true (internal default) prio = 0 uid = 05:83 (cache) and: No matching wwid [05:83] in bindings file. Created new binding [mpath0] for WWID [05:83] pgpolicy = failover (config file default) selector = round-robin 0 (internal default) features = 0 (internal default) hwhandler = 0 (internal default) rr_weight = 2 (config file default) rr_min_io = 100 (config file default) no_path_retry = -1 (config file default) pg_timeout = NONE (internal default) 0 28452960 multipath 0 0 2 1 round-robin 0 1 1 8:0 100 round-robin 0 1 1 8:64 100 set ACT_CREATE: map does not exists message mpath0 0 switch_group 1 create: mpath0 (05:83) [size=13 GB][features="0"][hwhandler="0"] \_ round-robin 0 \_ 1:0:0:0 sda 8:0 [ready] \_ round-robin 0 \_ 2:0:0:0 sde 8:64 [ready] Some (hopefully) final questions for you (or whoever knows)... 1) does the actual WWID need to be in the "uid" value that multipath gets from the callout, or is any value that is unique to the disk good enough? 2) what is the character limit to the return value from the getuid_callout? 3) is there a specific format that multipath is looking at for parsing the info in the uid value (such as vendor, model, type, serial number, etc), or is the unique disk identifier all that is needed? With those answers, I think I'll have a lock on this. Thanks, Rick -----Original Message----- From: malahal@xxxxxxxxxx [mailto:malahal@xxxxxxxxxx] Sent: Wednesday, January 30, 2008 3:11 PM To: Greene, Rick Cc: device-mapper development Subject: Re: Multipath and getuid_callout issues withHPXP1024disk array Greene, Rick [rick.greene@xxxxxxxxxxxx] wrote: > getuid = /sbin/xpdisk %n (internal default) > error calling out /sbin/xpdisk sda > uid = (callout) It prints your getuid call as "internal default", that is odd. That looks like a bug if you are just changing multipath.conf. I just tested my SLES10 SP1 system (multipath-tools-0.4.7-34.18) with /sbin/uid shell script that contains the following two lines. The first line is needed, do you have that in your shell script? #!/bin/sh echo $1 It woks and few lines of multipath -v3 output: sda: serial = 3EL0585G00007115JK65 sda: getprio = NULL (internal default) sda: prio = 1 sda: getuid = /sbin/uid %n (config file default) sda: uid = sda (callout) > > Run manually, it looks like this: > # /sbin/xpdisk sda > 0HP_OPEN-E_50060e80039c5a0400000000000000000000e100_05:83 > > I've tried various things with the script I wrote, including just > spitting out the 05:83 (which is the CU:LDev values from the disk array, > pretty much the most unique disk identifying info I can find) > > Not sure what else to do. > > Thanks, > Rick > > -----Original Message----- > From: dm-devel-bounces@xxxxxxxxxx [mailto:dm-devel-bounces@xxxxxxxxxx] > On Behalf Of malahal@xxxxxxxxxx > Sent: Wednesday, January 30, 2008 1:50 PM > To: dm-devel@xxxxxxxxxx > Subject: Re: Multipath and getuid_callout issues with > HPXP1024disk array > > You have two default sections in your multipath.conf file, but that is > not > the problem though. The scsi_id output from each path looks different, > that is why multipath treats them as different LUNs. > > Make sure you configure your storage properly or change the default > getuid string that works for your storage. > > Thanks, Malahal. > > Greene, Rick [rick.greene@xxxxxxxxxxxx] wrote: > > Ok, some more background first: > > > > System is an HP Proliant DL380 (or maybe DL580?), using Emulex fibre > > channel cards (don't know exact model off-hand). > > > > Running Red Hat Enterprise Linux 4, update 5. > > > > Device-mapper-multipath was version 0.4.5-21, just updated it to > > 0.4.5-27 > > > > There are 4 LUNs from an HP XP1024 disk array, each pathed to be > visible > > on each fibre channel. LUN type is OPEN-E. > > > > Multipath now seems to accept the longer string returned by scsi_id, > but > > it doesn't seem able to tell that certain disks are the same. > > > > Attached is the multipath.conf file I'm using and the output from > > "multipath -v3". If the attachments don't come through, I'll send > > separate emails with just the contents for each file. > > > > Any aide gladly received, I'm in over my head on this one. > > > > Thanks, > > Rick > > > > > > -----Original Message----- > > From: dm-devel-bounces@xxxxxxxxxx [mailto:dm-devel-bounces@xxxxxxxxxx] > > On Behalf Of malahal@xxxxxxxxxx > > Sent: Tuesday, January 29, 2008 5:19 PM > > To: dm-devel@xxxxxxxxxx > > Subject: Re: Multipath and getuid_callout issues with HP > > XP1024disk array > > > > Greene, Rick [rick.greene@xxxxxxxxxxxx] wrote: > > > I've done what I can to try to understand how all this works, but > I > > keep > > > getting "error calling out /sbin/scsi_id -g -u -s /block/sda" > when > > I run > > > the command "multipath -v2" > > > > > > > > > > > > I've tried a number of different things in the > /etc/multipath.conf > > file, > > > but keep coming back to this same error. If I run the command > > manually I > > > get the following: > > > > > > > > > > > > # /sbin/scsi_id -g -u -s /block/sda > > > > > > 0HP______OPEN-E__________50060e80039c5a0400000000000000000000e100 > > > > > > > > > > > > What's missing? Any help greatly appreciated. > > > > You are not missing anything. The device id is too big to fit in > > multipath tools allocated memory. The program incorrectly prints that > > there is a problem while executing /sbin/scsi_id but in fact the > problem > > lies in the program itself. You may have some old version of multipath > > tools. WWID_SIZE was set to 64 bytes and that is small for your > device. > > Get the latest version where that macro is set to 128 or so. > > > > Hope that helps! > > > > --Malahal. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
