Mapping LUNs to multipath devices.

larold · 02-04-2010, 02:35 PM

We are working with a Hitachi vendor to get multiple LUNs presented to our Linux servers. (OEL 5.4, effectively, Redhat 5.4)

The scsi_id command is returning long hex strings as expected. According to the scsi_id man page, these are the serial numbers of the LUNs. However, our Hitachi vendor let me know that there are no identifiers that she can find that match up, with anything CLOSE, to what I'm seeing. (I know scsi_id will prefix the identifier with a character) In other words, when I show her the output of scsi_id, or multipath -ll, it's meaningless to her, and she can't correlate that with a specific LUN.

Now, when doing an ls -l on /dev/disk/by-path, she recognized parts of the filesnames as identifiers corresponding to the wwn's of the individual paths (All 140+). Unfortunately, I have no knowledge of how to map that back to the LUNs and LUN id's I'm seeing in multipath / scsi_id output.

What's the best way to take the hex strings I'm seeing from scsi_id, and correlate them to the specific LUNs on the Hitachi side of things? I want to come up with useful device file names in /dev/mapper/, instead of the nebulous and generic 'mpathXX' names.

Thanks!

innocenti · 02-04-2010, 02:54 PM

Hallo Larold,

Are you able to post the multipath.conf?
May I can help you.

(I am not able to post a reaction then next monday)

Regards,
Eric

jonesr · 02-05-2010, 12:06 PM

Quote:

Originally Posted by larold

...I want to come up with useful device file names in /dev/mapper/, instead of the nebulous and generic 'mpathXX' names.

You can edit /var/lib/multipath/bindings to control the names of the bindings.

anomie · 02-05-2010, 01:51 PM

Not sure if this will help or not, but you may be able to ring a bell with Hitachi support by correlating multipath -ll output with the contents of /proc/scsi/scsi.

Example:

Code:

mpath200 (360060e80058a680000008a680000001e) dm-204 HITACHI,OPEN-V
[size=26G][features=1 queue_if_no_path][hwhandler=0][rw]
\_ round-robin 0 [prio=4][enabled]
 \_ 2:0:0:14  sddq  71:128  [active][ready]
 \_ 1:0:1:14  sdkv  67:304  [active][ready]
 \_ 1:0:0:14  sdp   8:240   [active][ready]
 \_ 2:0:1:14  sdvt  68:752  [active][ready]

.. matches ..

Code:

Host: scsi2 Channel: 00 Id: 00 Lun: 14
  Vendor: HITACHI  Model: OPEN-V           Rev: 6004
  Type:   Direct-Access                    ANSI SCSI revision: 03

(At least that's my understanding.)

innocenti · 02-07-2010, 02:35 PM

Hallo Larold,

It possible to configuire multipath to show the LUN ID's. thats the reason to see your mulipath.conf.

If that is not possible, to morrow I can give you an example.

Regards,
Eric

larold · 02-07-2010, 04:14 PM

Quote:

Originally Posted by innocenti

Hallo Larold,

It possible to configuire multipath to show the LUN ID's. thats the reason to see your mulipath.conf.

If that is not possible, to morrow I can give you an example.

Regards,
Eric

I know that it's possible to see LUN ids, as reported to Linux, in multipath output. However, that does me no good, as there's nothing in the SAN interface that correlates BACK to those LUN ids.

However, I was able to take a look in /proc/scsi/scsi and come up with an apparent mapping based on channel/id/lun combinations.

innocenti · 02-09-2010, 12:45 PM

Hallo Larold,

Do you need an output like:

Code:

# ll /dev/mapper
total 0
brw-rw---- 1 root disk 253, 15 Jan 19 08:19 360050768018180a4f800000000000163
brw-rw---- 1 root disk 253, 16 Jan 19 08:19 360050768018180a4f800000000000164
brw-rw---- 1 root disk 253, 13 Jan 19 08:19 36005076801858047b800000000000163
brw-rw---- 1 root disk 253, 14 Jan 19 08:19 36005076801858047b800000000000164

ll /dev/mpath/
total 0
lrwxrwxrwx 1 root root 8 Jan 19 08:19 360050768018180a4f800000000000163 -> ../dm-15
lrwxrwxrwx 1 root root 8 Jan 19 08:19 360050768018180a4f800000000000164 -> ../dm-16
lrwxrwxrwx 1 root root 8 Jan 19 08:19 36005076801858047b800000000000163 -> ../dm-13
lrwxrwxrwx 1 root root 8 Jan 19 08:19 36005076801858047b800000000000164 -> ../dm-14

To achive these multipath.conf look like:

Code:

##
## Use user friendly names, instead of using WWIDs as names.
#defaults {
#       user_friendly_names yes
#}

defaults {
        udev_dir                /dev
        polling_interval        10
        selector                "round-robin 0"
        path_grouping_policy    multibus
        getuid_callout          "/sbin/scsi_id -g -u -s /block/%n"
        prio_callout            /bin/true
        path_checker            readsector0
        rr_min_io               100
        rr_weight               priorities
        failback                immediate
        no_path_retry           fail
#        user_friendly_name      yes
}

Will these help?

Regardss,
Eric

jag1506 · 02-11-2010, 03:07 PM

cat /proc/scsi/scsi

and map them using partitions instead uid, of course you need fdisk and mk2fs to give them a filesystem before mounting, if you get errors because of different partitions been recognized uppon reboot or connection problems, you'll definitely need to use uid.

anomie · 02-19-2010, 07:17 PM

@larold: If you should happen to still be following this thread, does your Hitachi SAN use Storage Navigator? If so, you can match the last two (hex) bytes of Storage Navigator's LDKC:CU:LDEV to the last two (hex) bytes of the LUN's WWID as it appears in RHEL.

Let me know if that doesn't make sense. I am tacking this info on because I just had to go through reconciling Hitachi LUNs to RHEL5 this week, so glean a thing or two from my headache.

---

As for the other part of your question, you can manually manipulate the values in /var/lib/bindings to use the aliases you desire. (There are other ways to achieve the same result, BTW.)

Important reading on this topic, IMO:

larold · 02-20-2010, 11:31 AM

Quote:

Originally Posted by anomie

@larold: If you should happen to still be following this thread, does your Hitachi SAN use Storage Navigator? If so, you can match the last two (hex) bytes of Storage Navigator's LDKC:CU:LDEV to the last two (hex) bytes of the LUN's WWID as it appears in RHEL.

Let me know if that doesn't make sense. I am tacking this info on because I just had to go through reconciling Hitachi LUNs to RHEL5 this week, so glean a thing or two from my headache.

---

As for the other part of your question, you can manually manipulate the values in /var/lib/bindings to use the aliases you desire. (There are other ways to achieve the same result, BTW.)

Important reading on this topic, IMO:

Thanks much. You're exactly right - the Hitachi rep found the same thing.
She helped me match up the Hitachi IDs against the last two hex digits
in the UUID RHEL was seeing.

Thanks much!