Fun with iSCSI target and initiator

[Stephen Borrill <netbsd%precedence.co.uk@localhost>]

I've got the pkgsrc iSCSI target and initiator speaking well together; in 
fact, it Just Worked.

I'm now jumping ahead and trying 3rd party targets and initiators.

Aside: iscsifs man page issues:
-------------------------------

-v flag does not perform as described in the man page.

I'm struggling to parse the -t flag description "Connect to 
the number of the iSCSI target running as the argument".

virtdir(3) referred to in iscsifs(8) doesn't exist.

It appears to be mandatory to provide a username with the -u option even 
though the man page says (tersely) "The mandatory parameter is the local 
mount point.":

builder# iscsifs -h 192.168.1.101 /mnt
pid 21735:iscsifs.c:593: ***ERROR*** user must be specified with -ubuilder#
(all on one line - yes, there is a missing CR after the error message).

NetBSD target + 3rd party initiator:
------------------------------------
- The Windows XP initiator v1.08 works brilliantly.
- XenServer 5.5 finds the IQN, but fails to find any LUNs. The GUI error 
message is unhelpful "failed to complete the operation". From the command 
line:
[root@xenserver1 ~]# xe sr-create name-label=NetBSDiSCSI content-type=user 
device-config-target=192.168.1.1 device-config-targetIQN=iqn.1994-04.org.netbsd.iscsi-target:target0 device-config-localIQN=iqn.2008-10.com.example:004d2823 type=lvmoiscsi 
shared=false device-config-LUNid=0
There was an SR backend failure. 
status: non-zero exit stdout:
stderr: Traceback (most recent call last):
  File "/opt/xensource/sm/LVMoISCSISR", line 245, in ?
    SRCommand.run(LVHDoISCSISR, DRIVER_INFO)
  File "/opt/xensource/sm/SRCommand.py", line 148, in run
    sr = driver(cmd, cmd.sr_uuid)
  File "/opt/xensource/sm/SR.py", line 118, in __init__
    self.load(sr_uuid)
  File "/opt/xensource/sm/LVMoISCSISR", line 86, in load
    self._LUNprint(sr_uuid)
  File "/opt/xensource/sm/LVMoISCSISR", line 147, in _LUNprint
    self.iscsi.print_LUNs()
  File "/opt/xensource/sm/ISCSISR.py", line 541, in print_LUNs
    obj._query(vdi_path, LUNid)
  File "/opt/xensource/sm/LUNperVDI.py", line 34, in _query
    self.uuid = 
scsiutil.gen_uuid_from_string(scsiutil.getuniqueserial(path))
  File "/opt/xensource/sm/scsiutil.py", line 73, in gen_uuid_from_string
    raise util.CommandException(1)

iscsiadm looks healthy to my untrained eyes:

[root@xenserver1 ~]# iscsiadm -m session
iscsiadm: No active sessions.
[root@xenserver1 ~]# iscsiadm -m discovery -p 192.168.1.1 -l
192.168.1.1:3260,1 iqn.1994-04.org.netbsd.iscsi-target:target0
[root@xenserver1 ~]# iscsiadm -m session
iscsiadm: No active sessions.
[root@xenserver1 ~]# iscsiadm -m node -T 
iqn.1994-04.org.netbsd.iscsi-target:target0 -p 192.168.1.1 -l
Login session [iface: default, target: 
iqn.1994-04.org.netbsd.iscsi-target:target0, portal: 192.168.1.1,3260]

3rd party target + NetBSD initiator:
------------------------------------
Target is an IBM DS3300 SAN. This requires host access to be configured 
which involves defining the initiator IQNs and then granting them access 
to the storage with a given LUN. The initiator OS must be given; I tried a 
few different ones including Linux and Windows 2003. After connecting for 
the first time, the SAN spots the initiator IQN "iqn.1994-04.org.netbsd.iscsi-initiator:agc" 
(how can the initiator IQN be altered? Why agc beside it being the 
author's name?). I then granted access to the storage from this IQN.

builder# iscsifs -u nulltest -h 192.168.1.101 /mnt
pid 15494:initiator.c:702: ***ERROR*** Target is not allowing access
pid 15494:initiator.c:1160: ***ERROR*** enqueue_worker: discovery_phase() 
failed (ignoring command)

The same process with XenServer + IBM SAN works fine (of course).

I'm going to attempt to try the initiator in -current.

--
Stephen