On Wed, Jul 28, 2010 at 1:26 PM, Jonathan Barber wrote:
# lspci | grep QLogic
0d:00.0 Fibre Channel: QLogic Corp. ISP2432-based 4Gb Fibre Channel to
PCI Express HBA (rev 03)
0d:00.1 Fibre Channel: QLogic Corp. ISP2432-based 4Gb Fibre Channel to
PCI Express HBA (rev 03)
# ls -l /sys/class/fc_host/host?/device
lrwxrwxrwx 1 root root 0 Jul 28 11:54 /sys/class/fc_host/host1/device
-> ../../../devices/pci0000:00/0000:00:06.0/0000:0b:00.0/0000:0c:09.0/0000:0d:00.1/host1
lrwxrwxrwx 1 root root 0 Jul 28 11:55 /sys/class/fc_host/host0/device
-> ../../../devices/pci0000:00/0000:00:06.0/0000:0b:00.0/0000:0c:09.0/0000:0d:00.0/host0
(note the 0d:00.0 and 0d:00.1 PCI ID in the symlink targets)
And I believe:
# ls -l /sys/block/*/device
will show you the relationship between the block device and the FC
port you were looking for in d).
I would interpret your missing block devices as being each of your
target HBA seeing only one of the storage controllers, and not both -
but check the output of "ls -l /sys/block/{sdao,sdd}/device" to make
sure.
Thanks for your answer Jonathan,
In my case I got
Jul 27 17:54:58 orastud1 kernel: qla2xxx 0000:06:00.0: SNS scan failed -- assuming zero-entry result...
and I'm sure both the controllers were visible as this is the passive node of a 2 nodes cluster with same SAN visibility between nodes.
And the other node (the active one) had same fc-switch config and no problem at all with the paths.
Now the problem is solved for this node (probably it was a matter of a changed but not activated config... because a group of SAN disks was swapped) and I get:
# ls -l /sys/class/fc_host/host?/device
lrwxrwxrwx 1 root root 0 Jul 27 18:16 /sys/class/fc_host/host1/device -> ../../../devices/pci0000:00/0000:00:07.0/0000:06:00.0/host1
lrwxrwxrwx 1 root root 0 Jul 27 18:16 /sys/class/fc_host/host2/device -> ../../../devices/pci0000:00/0000:00:07.0/0000:06:00.1/host2
]# ls -l /sys/block/*/device
lrwxrwxrwx 1 root root 0 Jul 27 18:16 /sys/block/sdaa/device -> ../../devices/pci0000:00/0000:00:07.0/0000:06:00.1/host2/rport-2:0-2/target2:0:2/2:0:2:12
lrwxrwxrwx 1 root root 0 Jul 27 18:16 /sys/block/sdab/device -> ../../devices/pci0000:00/0000:00:07.0/0000:06:00.1/host2/rport-2:0-2/target2:0:2/2:0:2:13
lrwxrwxrwx 1 root root 0 Jul 27 18:16 /sys/block/sdac/device -> ../../devices/pci0000:00/0000:00:07.0/0000:06:00.0/host1/rport-1:0-2/target1:0:2/1:0:2:13
lrwxrwxrwx 1 root root 0 Jul 27 18:16 /sys/block/sdad/device -> ../../devices/pci0000:00/0000:00:07.0/0000:06:00.1/host2/rport-2:0-2/target2:0:2/2:0:2:14
[snipped... long output]
I can see that all the host1 lines contain 06:00.0 (and 1:0:x:y devices at the end), while all the host2 lines contain 06:00.1 (and 2:0:x:y for device at the end)
In case of similar situation I would only have to see if
a) I have a mix of host1 and host2 disks lines
==> each hba is seeing only one path;
b) I have only hostx lines
==> I have only 1 hba involved in LUN visibility problems: the hosty missing in output above (and related pci id)...
and then with
cat /sys/class/fc_host/hosty/port_name
I would get its wwpn to pass to SAN guys
Thanks!
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
