Hi Mike,
On Tue, 2014-06-10 at 00:11 -0400, Mike Sponsler wrote:
> I'm having some trouble getting shared storage to work with LIO/targetcli
>
> This is my first time using this, so I'm learning a lot! But I'm stuck.
>
> I've got a single server running LIO as the SCSI target over a 4GB FC
> (Qlogi 24xx HBA) that I am attempting to share to 3x servers over the
> FC SAN (all Qlogic 24xx HBA)
>
> I have a Linux LVM target setup, and shared with ACL. I can access
> the LUN over the SAN from one of the servers:
>
> SCSI Target:
> [root@storage /]# targetcli
> targetcli shell version 2.1.fb35
> Copyright 2011-2013 by Datera, Inc and others.
> For help on commands, type 'help'.
>
> /> ls
> o- / .........................................................................................................................
> [...]
> o- backstores
> ..............................................................................................................
> [...]
> | o- block ..................................................................................................[Storage Objects: 1]
> | | o- VOE .............................................................[/dev/SANVolGroup00/VOEvol (1.0TiB) 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.2100001b3207881f.............................................................................................[gen-acls]
> | | o- acls ............................................................................................................[ACLs: 3]
> | | | o- naa.2100001b320e9121...................................................................................[Mapped LUNs: 1]
> | | | | o- mapped_lun0.....................................................................................[lun0 block/VOE (rw)]
> | | | o- naa.2100001b320edb20...................................................................................[Mapped LUNs: 1]
> | | | | o- mapped_lun0.....................................................................................[lun0 block/VOE (rw)]
> | | | o- naa.2100001b328b9cd8...................................................................................[Mapped LUNs: 1]
> | | | o- mapped_lun0.....................................................................................[lun0 block/VOE (rw)]
> | | o- luns ............................................................................................................[LUNs: 1]
> | | o- lun0............................................................................[block/VOE (/dev/SANVolGroup00/VOEvol)]
> | o- naa.2100001b3207d41e.............................................................................................[gen-acls]
> | o- acls ............................................................................................................[ACLs: 3]
> | | o- naa.2101001b322e9121...................................................................................[Mapped LUNs: 1]
> | | | o- mapped_lun0.....................................................................................[lun0 block/VOE (rw)]
> | | o- naa.2101001b322edb20...................................................................................[Mapped LUNs: 1]
> | | | o- mapped_lun0.....................................................................................[lun0 block/VOE (rw)]
> | | o- naa.2101001b32ab9cd8...................................................................................[Mapped LUNs: 1]
> | | o- mapped_lun0.....................................................................................[lun0 block/VOE (rw)]
> | o- luns ............................................................................................................[LUNs: 1]
> | o- lun0............................................................................[block/VOE (/dev/SANVolGroup00/VOEvol)]
> o- sbp ..............................................................................................................[Targets: 0]
> o- vhost ............................................................................................................[Targets: 0]
> />
>
Your config looks OK..
>
> I'm using multipath! Server one sees the two devices properly, and
> creates the multipath device:
>
> mpatha (36001405a04c6148b87f4969998829d32) dm-4 LIO-ORG ,VOE
> size=1.0T features='0' hwhandler='0' wp=rw
> |-+- policy='service-time 0' prio=0 status=active
> | `- 14:0:1:0 sdc 8:32 active undef running
> `-+- policy='service-time 0' prio=0 status=enabled
> `- 15:0:0:0 sdb 8:16 active undef running
>
Just FYI, most folks use something along the following to enable the
alua hwhandler, instead of the default hwhandler..
# cat /etc/multipath.conf
devices {
device {
vendor "LIO-ORG"
path_grouping_policy group_by_prio
path_checker tur
prio alua
hardware_handler "1 alua"
failback immediate
rr_weight uniform
no_path_retry 12
rr_min_io 100
}
}
> I'm not getting access to the LUN on the other servers:
>
> [root@compute2 ~]# multipath -r
> Jun 09 23:59:47 | mpatha: ignoring map
>
>
> I don't see the devices, sdc or sdb listed in the multipath
> information....so it can't create the multipath device on the other
> two nodes.
>
> I'm thinking that since the first initiator has SCSI reservation, the
> two other can't get access.
>
Nope, the linux initiator does not send out SCSI reservations, nor would
reservations prevent a LUN probe from occurring.
> How do I enable shared storage so all three devices can read/write to
> the device? Yes, I'm planning on using a cluster to manage the shared
> storage access.
>
First, try issuing a LIP to the FC host ports on the other two
initiators that aren't detected the LUNs via:
echo 1 > /sys/class/fc_host/$HOSTNO/issue_lip
This will query the fabric and attempt to login to any FC targets that
have become available. This is usually why LUNs aren't detected after
NodeACLs for FC Initiator WWPNs have been configured in targetcli.
Also, I'd recommend reading the following to understand what's going
when configuring qla2xxx ports from targetcli with 'gen-acls' set:
http://www.spinics.net/lists/target-devel/msg06008.html
http://www.spinics.net/lists/target-devel/msg06010.html
One other useful thing you can do on the target is to enable qla2xxx
debugging at modprobe qla2xxx time with:
modprobe qla2xxx ql2xextended_error_logging=0x1e40f000
and enabling tcm_qla2xxx debugging (via debugfs +
CONFIG_DYNAMIC_DEBUG=y) with:
echo 'module tcm_qla2xxx +p' > /debug/dynamic_debugging/control
However, I suspect your hitting the scenario in the target-devel threads
above, so I'd recommend trying this approach first.
--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
