Problem connecting iscsi lun: DID_TRANSPORT_DISRUPTED...

[PYL]

I'm not able to connect to a iscsi lun. I use proxmox ve 1.7 but I
have installed the kernel 2.6.36.2 to fix a bug with my network card
drivers...

What am I missing?

Here is the output from /var/log/messages:

[CODE]
Jan 14 14:57:13 fl-vm01 kernel: vmbr1: received packet on bond0.222
with own address as source address
Jan 14 14:57:13 fl-vm01 kernel: scsi3 : iSCSI Initiator over TCP/IP
Jan 14 14:57:13 fl-vm01 kernel: scsi 3:0:0:0: Direct-Access
NETAPP LUN 7330 PQ: 0 ANSI: 4
Jan 14 14:57:13 fl-vm01 kernel: sd 3:0:0:0: Attached scsi generic sg3
type 0
Jan 14 14:57:13 fl-vm01 kernel: sd 3:0:0:0: [sdb] 1258450944 512-byte
logical blocks: (644 GB/600 GiB)
Jan 14 14:57:13 fl-vm01 kernel: sd 3:0:0:0: [sdb] Write Protect is off
Jan 14 14:57:13 fl-vm01 kernel: sd 3:0:0:0: [sdb] Write cache:
disabled, read cache: enabled, doesn't support DPO or FUA
Jan 14 14:57:23 fl-vm01 kernel: connection1:0: detected conn error
(1011)
Jan 14 14:57:37 fl-vm01 kernel: connection1:0: detected conn error
(1011)
Jan 14 14:57:52 fl-vm01 kernel: connection1:0: detected conn error
(1011)
Jan 14 14:58:07 fl-vm01 kernel: connection1:0: detected conn error
(1011)
Jan 14 14:58:22 fl-vm01 kernel: connection1:0: detected conn error
(1011)
Jan 14 14:58:27 fl-vm01 kernel: sd 3:0:0:0: [sdb] Test WP failed,
assume Write Enabled
Jan 14 14:58:37 fl-vm01 kernel: connection1:0: detected conn error
(1011)
Jan 14 14:58:37 fl-vm01 kernel: sd 3:0:0:0: [sdb] Unhandled error code
Jan 14 14:58:37 fl-vm01 kernel: sd 3:0:0:0: [sdb] Result:
hostbyte=DID_TRANSPORT_DISRUPTED driverbyte=DRIVER_OK
Jan 14 14:58:37 fl-vm01 kernel: sd 3:0:0:0: [sdb] CDB: Read(10): 28 00
00 00 00 00 00 00 08 00
Jan 14 14:58:52 fl-vm01 kernel: connection1:0: detected conn error
(1011)
Jan 14 14:59:07 fl-vm01 kernel: connection1:0: detected conn error
(1011)
Jan 14 14:59:22 fl-vm01 kernel: connection1:0: detected conn error
(1011)
Jan 14 14:59:37 fl-vm01 kernel: connection1:0: detected conn error
(1011)
[/CODE]While the timeout occurs, if I issue the command "iscsiadm -m
session -P 3" the output is:

[CODE]
iSCSI Transport Class version 2.0-870
iscsiadm version 2.0-870
Target: iqn.1986-03.com.ibm:sn.118072897
Current Portal: 10.10.10.11:3260,2002
Persistent Portal: 10.10.10.11:3260,2002
**********
Interface:
**********
Iface Name: default
Iface Transport: tcp
Iface Initiatorname: iqn.2005-03.org.open-iscsi:201ac9f61a90
Iface IPaddress: 10.10.10.20
Iface HWaddress: default
Iface Netdev: default
SID: 1
iSCSI Connection State: IN LOGIN
iSCSI Session State: FAILED
Internal iscsid Session State: REPOEN
************************
Negotiated iSCSI params:
************************
HeaderDigest: None
DataDigest: None
MaxRecvDataSegmentLength: 131072
MaxXmitDataSegmentLength: 65536
FirstBurstLength: 65536
MaxBurstLength: 65536
ImmediateData: Yes
InitialR2T: No
MaxOutstandingR2T: 1
************************
Attached SCSI devices:
************************
Host Number: 3 State: running
scsi3 Channel 00 Id 0 Lun: 0
Attached scsi disk sdb State: blocked
[/CODE]Anyone knows how I can solve this one?

The SAN is an IBM System Storage N series N7900 with NetApp...

What can I do to investigate that problem further?
Thanks!

[Mike Christie]

We seem to be getting them around every 15 seconds, so I think a scsi
command is timing out which is starting the scsi eh and we end up
dropping the session and relogging in because TMFs do not work.

You could do

echo 1 > /sys/module/libiscsi/parameters/debug_libiscsi_eh

then rerun your test to confirm this.

I do not know why the command is timing out though. Is there anything in
the target logs? If you create a smaller LU (just a couple gigs) does it
work then?

[Pierre-Yves Langlois]

After issuing the command  "echo 1 > /sys/module/libiscsi/parameters/debug_libiscsi_eh",I didn't see any changes in /var/log/messages, /var/log/kern.log, /var/log/daemon.log, /var/log/debug. Do I look at the right place?

[Mike Christie]

On 01/17/2011 02:26 PM, Pierre-Yves Langlois wrote:
> After issuing the command "echo 1>
> /sys/module/libiscsi/parameters/debug_libiscsi_eh",I didn't see any changes
> in
> /var/log/messages, /var/log/kern.log, /var/log/daemon.log, /var/log/debug.
> Do I look at the right place?
>

Did you do the echo, then relogin to the target?

echo 1 > /sys/module/libiscsi/parameters/debug_libiscsi_eh
iscsiadm -m node -u
iscsiadm -m node -l

[Pierre-Yves Langlois]

Hi Mike,

I made more test to debug my setup. My original setup uses a bond on 2 nic. If I only use one nic to connect to the SAN, everything works fine. The problem occurs when I use the bond... Does iscsi need a special configuration with bond or is it transparent to him?

Thanks! 

[Mike Christie]

On 01/18/2011 03:41 PM, Pierre-Yves Langlois wrote:
> Hi Mike,
>
> I made more test to debug my setup. My original setup uses a bond on 2 nic.
> If I only use one nic to connect to the SAN, everything works fine. The
> problem occurs when I use the bond... Does iscsi need a special
> configuration with bond or is it transparent to him?
>

It is transparent. iscsi_tcp runs from a high level. It basically just
opens a socket like other network apps then it does send()/recv() to
send/recv IO (recv is a little more complicated).

If you are using iscsi iface hwardare/session binding with iscsi_tcp
then it is more complicated. I am not sure if that combo would work.