1

From Red Hat Enterprise Linux 6 how can I tell the difference between a SAN zoning problem (e.g. cannot reach the storage at all) versus a LUN masking issue (e.g. LUNs not assigned to the right HBA WWN)?

On HP-UX (yeah, I know...) this is pretty simple-- the disk array presents targets with a different SCSI ID string in the "ioscan" output:

LUNs from that disk array show the virtual LUN emulation type "OPEN-V" (way over to the right):

target      11  0/5/2/0/4/0.117.7.0.0.0      tgt          CLAIMED     DEVICE
disk         3  0/5/2/0/4/0.117.7.0.0.0.0    sdisk        CLAIMED     DEVICE       HP      OPEN-V

The disk array itself shows "DISK-SUBSYSTEM" instead of "OPEN-V" on every SCSI target even if no LUNs are assigned:

target      16  0/5/2/0/4/0.117.7.0.0.5      tgt          CLAIMED     DEVICE
disk        29  0/5/2/0/4/0.117.7.0.0.5.0    sdisk        CLAIMED     DEVICE       HP      DISK-SUBSYSTEM

This could also simply be a result of choosing HPUX-compatible emulation on the array. I know ancient versions of HPUX got super angry when they saw a SCSI target without a LUN 0 present so the storage may be forcing itself to present a placeholder LUN 0 only in this emulation mode.

On Linux, is there a similar diagnostic test to help identify if the storage is visible at all (e.g. zoning is good, LUN assignments are bad) versus storage not visible at all (e.g. zoning is bad)?

"lsscsi", "lsblk", "blockdev --report", and "cat /proc/scsi/scsi" all seem to only report once the LUNs are visible all the way through (both zoning and LUN masking are good.)

I poked through /sys/class/scsi_generic thinking that perhaps a target assigned without a disk device might show up with at least a generic SCSI device, but the only sgX devices are those associated with disk block devices meaning the LUNs are working fine all the way from storage to host.

What do you use to help identify zoning vs. LUN assignment issues on Linux?

Steve Bonds
  • 1,014
  • 2
  • 12
  • 21
  • 1
    I'm not the right guy to answer this because I don't know enough about how to manipulate storage with Linux, but can tell you that if you can see the storage port but don't see the right LUNs, that's a masking issue. If you can't see the port at all, that's a zoning issue. – Basil Jan 31 '16 at 21:15
  • Also, you really don't want to have the host emulation for your storage set to HP-UX for Linux. This is set on the hostgroup level on HP's HDS storage, so I recommend that instead of adding the Linux WWNs to the existing hostgroup, you create a new one (on different ports) and set the host emulation to linux. – Basil Jan 31 '16 at 21:16
  • To clarify, the LUNs assigned to the Linux host do have the correct Linux emulation type. I provided the HP-UX example to show a method I use in a different environment to distinguish zoning issues vs. LUN assignment issues in the hopes of demonstrating more precisely what I'm looking for. – Steve Bonds Jan 31 '16 at 22:05
  • I thought I might have had something by poking through `/sys/class/fc_remote_ports/*/port_name` and looking for any WWN from the storage array. There was nothing visible with the first 6 bytes of the WWN the same as the storage array until there was a LUN assigned. – Steve Bonds Jan 31 '16 at 22:19
  • just a thought - if it was a zoning issue it'd affect ALL luns to that box , right ? whereas if it was a presentation issue it may only affect the lun/s per se ; steve - does your box have several luns presented ? – d0td0t Feb 09 '16 at 16:47
  • Even when it's LUN issues we typically see all-or-nothing. I was hoping there might be some kind of non-LUN device visible to Linux when the storage was zoned correctly but so far I have not found anything. – Steve Bonds Feb 09 '16 at 18:59
  • This article suggested some things for me to try next time: https://access.redhat.com/articles/17054. The environment where I could test this no longer exists, but in case Future Me (or anyone else!) needs to troubleshoot this, the info in /sys/class/fc_transport/* (especially port_name) could be useful. To find the LUN wwid, the "sg_inq -p 0x83 /dev/sdN" command can be used to hit that LUN with a SCSI_ID command. Good luck Future Me (or others)! – Steve Bonds Jun 13 '17 at 15:45

0 Answers0