On Thu, Feb 11, 2016 at 3:58 PM, Nicholas A. Bellinger <nab@xxxxxxxxxxxxxxx> wrote: > On Thu, 2016-02-11 at 09:44 -0800, Schlacta, Christ wrote: >> I apologize, as last night I accidentally replied off-list to this >> thread due to a mis-configured list. I've recreated the messages >> below, updated the time, and corrected a typo. >> >> >> On Thu, Feb 11, 2016 at 12:00 AM, Nicholas A. Bellinger >> <nab@xxxxxxxxxxxxxxx> wrote: >> > On Wed, 2016-02-10 at 18:36 -0800, Schlacta, Christ wrote: >> >> I'm trying to run lio with targetcli and tcm_qla2xxx and of course >> >> qla2xxx on debian jessie with kernel debian 3.16.0-4, and I'm running >> >> into the strangest issue. I'm seeing everything as apparently correct >> >> in targetcli, with no unexpected errors in dmesg or otherwise. The >> >> card works fine, as it functioned correctly with scst, but I get only >> >> one device on the initiator now, and it's not any of the devices I've >> >> configured. It appears as follows in the client on QConvergeConsole >> >> (The management software for the windows driver): >> >> >> >> Product Vendor: >> >> LIO-ORG >> >> Product ID: >> >> RAMDISK-MCP >> >> Product Revision: >> >> 4.0 >> >> LUN: >> >> 0 >> >> Size: >> >> Unknown >> >> Type: >> >> Unknown >> >> WWULN: >> >> 4C-49-4F-2D-4F-52-47-00-00 >> >> >> > >> > The LUN=0 above is a Virtual LUN=0 provided by LIO to all demo-mode >> > target_core_mod sessions, when no matching explicit NodeACL + MappedLUNs >> > groups for LUN=0 within tcm_qla2xxx endpoint + port configfs exist. >> >> I figured it was something like that. For the record, scst provides no >> such nodes, and entire loops can have no nodes present, or even nodes >> that start above zero. It's useful for maintaining (virtual) disk -> >> lun mapping. > > Not sure how that relates to NodeACL + MappedLUNs here. > >> >> > >> >> I got no idea what to try, but I'm thinking about switching back to >> >> scst even though I upgraded to debian jessie to get in-kernel lio if I >> >> can't figure out what's wrong here. Tell me what you'd like to see, >> >> and I'll share it. Below are some log snippets that I doubt will be >> >> useful, but may be. >> >> >> >> [11717.118353] qla2xxx [0000:05:00.0]-505f:5: Link is operational (4 Gbps). >> >> [11717.527716] qla2xxx [0000:05:00.0]-1020:5: **** Failed mbx[0]=4005, >> >> mb[1]=4, mb[2]=8807, mb[3]=ffff, cmd=70 ****. >> >> [11717.528120] qla2xxx [0000:05:00.0]-0121:5: Failed to enable >> >> receiving of RSCN requests: 0x2. >> >> >> >> /qla2xxx/21:0...9d:12:dd/acls> ls / >> >> o- / .............................................. [...] >> >> o- backstores ................................... [...] >> >> | o- fileio ....................... [3 Storage Objects] >> >> | | o- izanami01 . [256.0G, /vdisk02/izanami01, in use] >> >> | | o- test01 ....... [256.0G, /vdisk02/test01, in use] >> >> | | o- test02 ....... [256.0G, /vdisk02/test02, in use] >> >> | o- iblock ........................ [0 Storage Object] >> >> | o- pscsi ......................... [0 Storage Object] >> >> | o- rd_mcp ........................ [0 Storage Object] >> >> o- iscsi .................................. [0 Targets] >> >> o- loopback ............................... [0 Targets] >> >> o- qla2xxx ................................. [1 Target] >> >> | o- 21:00:00:1b:32:9d:12:dd ................ [enabled] >> >> | o- acls ................................... [1 ACL] >> >> | | o- 20:00:00:1b:32:9d:77:da ...... [3 Mapped LUNs] >> >> | | o- mapped_lun0 .................... [lun0 (rw)] >> >> | | o- mapped_lun1 .................... [lun1 (rw)] >> >> | | o- mapped_lun2 .................... [lun2 (rw)] >> >> | o- luns .................................. [3 LUNs] >> >> | o- lun0 . [fileio/izanami01 (/vdisk02/izanami01)] >> >> | o- lun1 ....... [fileio/test01 (/vdisk02/test01)] >> >> | o- lun2 ....... [fileio/test02 (/vdisk02/test02)] >> >> o- vhost .................................. [0 Targets] >> > >> > Looks fine as an NodeACL + MappedLUN for 20:00:00:1b:32:9d:77:da >> > >> > Please confirm your FC WWPN initiator port (non-NPIV) value >> > >> >> I'm not at the initiator now, but I'll check later. > > In recent versions of tcm_qla2xxx, there is a configfs attribute to list > which 'demo-mode' sessions are active: > > cat /sys/kernel/config/target/qla2xxx/$WWPN/tpgt_1/dynamic_sessions > > This will show which $INITIATOR_WWPN ports have logged in, vs. what's > currently configured in /qla2xxx/$WWPN/acls/$INITIATOR_WWPN/ for > explicit NodeACLs. I'm on 3.16.0-4 on debian wheezy, so I'm guessing this isn't a new enough version. Is there a DKMS package I can install newer modules with? That kinda defeats the purpose of switching to lio though > >> In the mean time, >> can I somehow disable acls, as there is only the two endpoints on the >> physical loop, and that's enough access control for testing purposes? >> (No switch) > > Yes, in targetcli under each /qla2xxx/$WWPN/ context, do: > > /> cd /qla2xxx/21:00:00:24:ff:48:97:7e/ > /qla2xxx/21:0...4:ff:48:97:7e> set attribute generate_node_acls=1 > cache_dynamic_acls=1 demo_mode_write_protect=1 > Parameter generate_node_acls is now '1'. > Parameter cache_dynamic_acls is now '1'. > Parameter demo_mode_write_protect is now '1'. Those are the default values already set. Are you sure some of them shouldn't be 0s? I can't find documentation on them anywhere. > > Keep in mind, if your initiator WWPNs has already logged in to the > individual target WWPN, and session instance is resident in memory. > > In order for the demo-mode changes to take effect on current sessions > without an explicit NodeACL, you'll want to 'saveconfig' and > then /etc/init.d/target restart. > -- 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
