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?
0 Answers