It turns out the cards I had were falsely advertised as QLE2662 and is why no matter what
I did, they wouldn't work. I checked with the SCST developer and it seems no luck
there since there's no support in the kernel for anything other than initiator mode.
I replaced them with some QLE2564/2562 and am getting MUCH closer with targetcli to making
it work.
I took a large /dev/sda drive and created a partition of two different sizes as sda1 and
sda2, one for working LVM space and the other for a backup volume.
Currently my target cli is set up like this:
o- /
.....................................................................................................................
[...]
o- backstores
..........................................................................................................
[...]
| o- block
..............................................................................................
[Storage Objects: 2]
| | o- vm_backup ..................................................................
[/dev/sda2 (0 bytes) write-thru activated]
| | | o- alua
...............................................................................................
[ALUA Groups: 1]
| | | o- default_tg_pt_gp
................................................................... [ALUA state:
Active/optimized]
| | o- vm_shared ..................................................................
[/dev/sda1 (0 bytes) write-thru activated]
| | o- alua
...............................................................................................
[ALUA Groups: 1]
| | o- default_tg_pt_gp
................................................................... [ALUA state:
Active/optimized]
| 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: 1]
| o- naa.21000024ff67440f
.........................................................................................
[gen-acls]
| o- acls
........................................................................................................
[ACLs: 1]
| | o- naa.21000024ff56a8a8
............................................................................... [Mapped
LUNs: 2]
| | o- mapped_lun0
........................................................................... [lun0
block/vm_shared (rw)]
| | o- mapped_lun1
........................................................................... [lun1
block/vm_backup (rw)]
| o- luns
........................................................................................................
[LUNs: 2]
| o- lun0 ...............................................................
[block/vm_shared (/dev/sda1) (default_tg_pt_gp)]
| o- lun1 ...............................................................
[block/vm_backup (/dev/sda2) (default_tg_pt_gp)]
o- vhost
........................................................................................................
[Targets: 0]
The naa.21000024ff67440f under qla2xxxx is the port_name of the target. Under acls,
naa.21000024ff56a8a8 is the port_name on the initiator. I used find /sys -name port_name |
xargs head to get those.
My initiator has a FreeNAS box tied to the second port so the sdb though sdf is the
FreeNAS box but lun0 part1 part2 **looks** like the target I'm trying to configure.
I'm not sure yet how to tell if that is the sda1&2 for the boot volume from this
view.
lrwxrwxrwx 1 root root 9 Feb 2 14:41 fc-0x21000024ff56a8a9-0x21000024ff6ba2cc-lun-0
-> ../../sdb
lrwxrwxrwx 1 root root 10 Feb 2 14:41
fc-0x21000024ff56a8a9-0x21000024ff6ba2cc-lun-0-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 9 Feb 2 14:41 fc-0x21000024ff56a8a9-0x21000024ff6ba2cc-lun-1
-> ../../sdc
lrwxrwxrwx 1 root root 10 Feb 2 14:41
fc-0x21000024ff56a8a9-0x21000024ff6ba2cc-lun-1-part1 -> ../../sdc1
lrwxrwxrwx 1 root root 9 Feb 2 14:41 fc-0x21000024ff56a8a9-0x21000024ff6ba2cc-lun-2
-> ../../sdd
lrwxrwxrwx 1 root root 10 Feb 2 14:41
fc-0x21000024ff56a8a9-0x21000024ff6ba2cc-lun-2-part1 -> ../../sdd1
lrwxrwxrwx 1 root root 9 Feb 2 14:41 fc-0x21000024ff56a8a9-0x21000024ff6ba2cc-lun-3
-> ../../sde
lrwxrwxrwx 1 root root 10 Feb 2 14:41
fc-0x21000024ff56a8a9-0x21000024ff6ba2cc-lun-3-part1 -> ../../sde1
lrwxrwxrwx 1 root root 9 Feb 2 14:41 fc-0x21000024ff56a8a9-0x21000024ff6ba2cc-lun-4
-> ../../sdf
lrwxrwxrwx 1 root root 10 Feb 2 14:41
fc-0x21000024ff56a8a9-0x21000024ff6ba2cc-lun-4-part1 -> ../../sdf1
lrwxrwxrwx 1 root root 9 Feb 2 14:41 fc---lun-0 -> ../../sda
lrwxrwxrwx 1 root root 10 Feb 2 14:41 fc---lun-0-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Feb 2 14:41 fc---lun-0-part2 -> ../../sda2
lrwxrwxrwx 1 root root 9 Feb 2 14:41 pci-0000:02:00.0-scsi-0:2:0:0 -> ../../sda
lrwxrwxrwx 1 root root 10 Feb 2 14:41 pci-0000:02:00.0-scsi-0:2:0:0-part1 ->
../../sda1
lrwxrwxrwx 1 root root 10 Feb 2 14:41 pci-0000:02:00.0-scsi-0:2:0:0-part2 ->
../../sda2
lrwxrwxrwx 1 root root 9 Feb 2 14:41 pci-0000:04:00.1-fc-0x21000024ff6ba2cc-lun-0 ->
../../sdb
lrwxrwxrwx 1 root root 10 Feb 2 14:41 pci-0000:04:00.1-fc-0x21000024ff6ba2cc-lun-0-part1
-> ../../sdb1
lrwxrwxrwx 1 root root 9 Feb 2 14:41 pci-0000:04:00.1-fc-0x21000024ff6ba2cc-lun-1 ->
../../sdc
lrwxrwxrwx 1 root root 10 Feb 2 14:41 pci-0000:04:00.1-fc-0x21000024ff6ba2cc-lun-1-part1
-> ../../sdc1
lrwxrwxrwx 1 root root 9 Feb 2 14:41 pci-0000:04:00.1-fc-0x21000024ff6ba2cc-lun-2 ->
../../sdd
lrwxrwxrwx 1 root root 10 Feb 2 14:41 pci-0000:04:00.1-fc-0x21000024ff6ba2cc-lun-2-part1
-> ../../sdd1
lrwxrwxrwx 1 root root 9 Feb 2 14:41 pci-0000:04:00.1-fc-0x21000024ff6ba2cc-lun-3 ->
../../sde
lrwxrwxrwx 1 root root 10 Feb 2 14:41 pci-0000:04:00.1-fc-0x21000024ff6ba2cc-lun-3-part1
-> ../../sde1
lrwxrwxrwx 1 root root 9 Feb 2 14:41 pci-0000:04:00.1-fc-0x21000024ff6ba2cc-lun-4 ->
../../sdf
lrwxrwxrwx 1 root root 10 Feb 2 14:41 pci-0000:04:00.1-fc-0x21000024ff6ba2cc-lun-4-part1
-> ../../sdf1
Suggestions?
Thank you,
Steffan Cline
steffan(a)hldns.com
602-793-0014
On 1/6/20, 6:46 AM, "Rainer Kamenik" <rainer.kamenik(a)tuwien.ac.at>
wrote:
Hello Steffan,
We have a lot of boxes running PBs of storage for many years under
Centos/LIO.
We never got it running stable with prepackaged RPMs. TRedHat does not
officially
support the FC fabric modul. It is very sensitive - you have to use a
adapter firmware version,
kernel and targetcli-fb version that play together and are considered to
be stable , but nobody on the
mailling-list will be able or wants to tell you what is stable, cause
there are maybe too
few people that use LIO with the FC fabric module. It is mostly used
with iSCSI and Infiniband fabrics.
We had the same problems when we started to use it years ago and ended
up installing the whole stuff
on a minimal Centos installation from scratch (Vanilla Kernel,
rtslib,configshell,targetcli, some python modules ...)
The versions on CentOS that we consider as stable are:
OS: Centos 7 with vanilla kernel 4.18.14
Target: tcm_qla2xxx
Stable boot Firmware: 8.07.80 (Firmware Flash via qaucli !)
Stable Qlogic driver for tcm_qla2xxx: 10.00.00.07-k (Kernel 4.18.14)
targetcli: Custom Install (/w Python 2.7)
rainer
--
--------------------------------------------------------------------
Rainer Kamenik | rainer.kamenik(a)tuwien.ac.at
IT Solutions - Server and Storage
TU Wien - Operngasse 11/020, 1040 Wien
T +43-1-58801-42077
--------------------------------------------------------------------
Show replies by date