<div class="gmail_quote">On Wed, Jul 28, 2010 at 1:26 PM, Jonathan Barber wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div class="im"> </div># 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. </blockquote></div> 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!