Hi Robert, (CC'ing target-devel) On Wed, 2013-10-09 at 11:27 -0700, Robert Lusby wrote: > Nicholas, > > I am sorry to bother you, but I have been searching Google for many > days trying to find some documentation on how to setup Fibre Channel > multipathing with targetcli. > > I have not had any luck. So I am contacting you for help. > > I have successfully configured targetcli to present a Fibre Channel > LUN to an initiator (VMware ESXi 5.1). > > I have a dual-port Qlogic Fibre Channel HBA and would like the LUN to > appear on both ports. Targetcli configuration is as follows: > > /> ls > o- / ....................................................................................... [...] > o- backstores ............................................................................ [...] > | o- block ................................................................ [Storage Objects: 1] > | | o- lun1 ......................................... [/dev/md126 (1.8TiB) write-thru activated] > | o- fileio ............................................................... [Storage Objects: 0] > | o- pscsi ................................................................ [Storage Objects: 0] > | o- ramdisk .............................................................. [Storage Objects: 0] > o- iscsi .......................................................................... [Targets: 0] > o- loopback ....................................................................... [Targets: 0] > o- qla2xxx ........................................................................ [Targets: 2] > | o- naa.210000e08b885aa6 ........................................................... [gen-acls] > | | o- acls .......................................................................... [ACLs: 1] > | | | o- naa.2100001b322f021a ................................................. [Mapped LUNs: 1] > | | | o- mapped_lun0 .................................................. [lun0 block/lun1 (rw)] > | | o- luns .......................................................................... [LUNs: 1] > | | o- lun0 ........................................................ [block/lun1 (/dev/md126)] > | o- naa.210100e08ba85aa6 ........................................................... [gen-acls] > | o- acls .......................................................................... [ACLs: 1] > | | o- naa.2100001b320f021a ................................................. [Mapped LUNs: 1] > | | o- mapped_lun0 .................................................. [lun0 block/lun1 (rw)] > | o- luns .......................................................................... [LUNs: 1] > | o- lun0 ........................................................ [block/lun1 (/dev/md126)] > o- vhost .......................................................................... [Targets: 0] > /> This all looks correct. > /> version > targetcli version 2.1.fb30 > /> > /> /qla2xxx info > Fabric module name: qla2xxx > ConfigFS path: /sys/kernel/config/target/qla2xxx > Allowed WWN types: naa > Allowed WWNs list: naa.210000e08b885aa6, naa.210100e08ba85aa6 > Fabric module features: acls > Corresponding kernel module: tcm_qla2xxx > /> > This is running on Fedora Linux 19. > > I figure it is some additional configuration parameter I am missing in > targetcli, but I do not know what it would be. > So implicit / explicit ALUA multipath is automatically enabled by default when a backend device (block/lun1 in the above case) is exported as a fabric LUN. There is nothing special required from targetcli to enable this, aside from exporting the same backend across multiple fabric LUNs as you've done above. Can you give a few more details on what the ESX client side is reporting, and how ALUA multipath is not working as you'd expect..? --nab -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
