Hi everyone,
My name is Alban and I'm trying to learn a bit more on STGT. I've
started using the iSCSI component and it's mostly been a good
experience, although recently I started running into some
difficulties.
Firstly, I wasn't sure if this is the best place to ask some technical
questions - apologies in advance if this is not the right audience.
Any pointers to the right direction would be greatly appreciated.
I've got an Ubuntu Server 12.04 (x64) installation with the default
version of stgt installed (i.e: Version: 1:1.0.17-1ubuntu2). This
installation has three iSCSI targets configured with one LUN per
target. No custom ACL configuration is present.
On the other hand, there are three Windows machines (Windows 7 and
above), from where these three iSCSI targets are accessed from. The
standard Microsoft Windows iSCSI Initiator is used for this purpose.
Every once in a while, after successfully disconnecting initiators and
removing the connected LUNs, targets don't seem to end up in a clean
state. What I mean by this is that some initiator connections remain
present in the target even after disconnecting initiators. As a
consequence, this prevents the targets from being removed. In such
situations, the target information may look like this:
Target 3: strauss.server3:for.all
System information:
Driver: iscsi
State: ready
I_T nexus information:
I_T nexus: 15
Initiator: iqn.1991-05.com.microsoft:server3
Connection: 1
IP Address: 192.168.1.42
I_T nexus: 16
Initiator: iqn.1991-05.com.microsoft:server3
Connection: 1
IP Address: 192.168.1.42
...
I_T nexus: 21
Initiator: iqn.1991-05.com.microsoft:server3
Connection: 1
IP Address: 192.168.1.42
LUN information:
LUN: 0
Type: controller
SCSI ID: IET 00030000
SCSI SN: beaf30
Size: 0 MB, Block size: 1
Online: Yes
Removable media: No
Readonly: No
Backing store type: null
Backing store path: None
Backing store flags:
Account information:
ACL information:
I had a look at the iSCSI server logs and I see reports that the iSCSI
server fails to close the connections:
When I list the connections with the following command:
> sudo tgtadm --lld iscsi --op show --mode conn --tid 3
I get to see all the connections reported above. However, when I
attempt to remove/close them:
> sudo tgtadm --lld iscsi --op delete --mode conn --tid 3 --sid 21 --cid 1
the command seems to succeed (i.e. it doesn't print any error
messages) but the actual connection is not removed. The corresponding
logs (/var/log/syslog) suggest that these connections are somehow
unaccounted for by tgt:
Aug 16 03:43:34 STRAUSS tgtd: conn_close_admin(235) close 15 1
Aug 16 03:43:34 STRAUSS tgtd: tgt_event_modify(213) Cannot find event 20
Aug 16 03:43:34 STRAUSS tgtd: iscsi_event_modify(413) tgt_event_modify failed
The same log keeps reporting that a tcp connection is broken:
Aug 16 03:40:49 STRAUSS tgtd: iscsi_tcp_show(390) Transport endpoint
is not connected
Looking at the logs on the Windows end, the initiator (iScsiPrt)
reports many difficulties with timeouts. The event log has many
entries that contain the following chain of events:
> (Warn) The description for Event ID 129 from source iScsiPrt cannot be found. ...
> (Error) Initiator sent a task management command to reset the target. The target name is given in the dump data.
> (Error) Target failed to respond in time to a Task Management request.
> (Error) Target did not respond in time for a SCSI request. The CDB is given in the dump data.
> (Error) Can not Reset the Target or LUN. Will attempt session recovery.
I've got two questions about the situation above:
1) is there any way to remove the described dangling connections from
the target? Failing this, is there a way to forcefully remove a target
that has such connections?
2) the initiator timeouts seem to be reported even when the iSCSI
server host is not loaded. I've been looking for information about any
performance tuning of the iSCSI server that would reduce these timeout
issues, but have had no luck so far. Is there anything that can be
done to reduce such timeouts?
Many thanks,
Alban
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
