On 03/01/2011 11:54 AM, oxide23 wrote:
I am connecting 2 iscsi arrays to the same network port on a linux box
over the network. One device works fine. The other gets the dreaded
conn(1011) errors.
What version of open-iscsi are you using? What is the kernel and are you
using the kernel modules with the kernel?
Is it always the same device?
eth1 Link encap:Ethernet HWaddr 00:1D:09:2F:15:B2
inet addr:128.128.101.92 Bcast:128.128.103.255 Mask:
255.255.252.0
iscsiadm -m iface
default tcp,<empty>,<empty>,<empty>,<empty>
iser iser,<empty>,<empty>,<empty>,<empty>
bnx2i.00:00:00:00:00:00 bnx2i,
00:00:00:00:00:00,<empty>,<empty>,<empty>
bnx2i.00:1d:09:2f:15:b1 bnx2i,00:1d:09:2f:
15:b1,<empty>,<empty>,<empty>
bnx2i.00:1d:09:2f:15:b3 bnx2i,00:1d:09:2f:
15:b3,<empty>,<empty>,<empty>
iface1 tcp,00:1D:09:2F:15:B2,<empty>,<empty>,<empty>
iscsiadm -m node
128.128.181.69:3260,1 iqn.1994-12.com.promise.dd.64.55.55.1.0.0.20
128.128.181.99:3260,1 iqn.2010.09.maxtronic.com:732af838098e3a24:ist1
128.128.181.51:3260,1 iqn.2010.09.maxtronic.com:732af838098e3a24:ist0
What is the output of "iscsiadm -m node -P 1"?
do I need to create an iface for each? is each considered a "network
object"? or can they share the one I created:
They can share one.
more /var/lib/iscsi/ifaces/iface1
iface.transport_name = tcp
iface.hwaddress = 00:1D:09:2F:15:B2
could this be the source of my conn(1011) disconnect errors in /var/
log/messages?
Normally, if the iface binding is not working then we would fail to even
connect, so you would not see the login successful message and you would
not get a target or device.
If your network configuration is changing while iscsi is running, then
that could cause a disruption and cause you get to get the 1011 errors.
Has anyone out there been able to get an "Arena SS-6603R" to work with
any iscsi version?
target discovery seems to work, and I can log in. However, the logs
fill up with this:
/var/log/messages.1:Feb 25 15:32:37 ndsfdh1 iscsid: Kernel reported
iSCSI connection 6:0 error (1011) state (3)
/var/log/messages.1:Feb 25 15:32:40 ndsfdh1 iscsid: connection6:0 is
operational after recovery (1 attempts)
I can then actually create a partition, create a file system on it and
then mount it. But after about 10-15 minutes, the filesystem becomes
unreadable and has to be unmounted/redone.
When you say it fills up with this messages do you mean it is
continuously happening after login, and also occurs while creating the
partition?
Is there anything else in the logs? Could you attach it?
Do you get those errors even when you are not doing any IO. So before
you do your partition and FS creation test when the system is more or
less idle, do you see those messages? If so check the target logs.
I've tried changing timeouts, however I don't know which timeouts are
the correct ones to change, by how much and if it will negatively
effect the working iscsi array. Are there some general troubleshooting
guidelines on which values are likely to have an effect and what
acceptable ranges are for operation? Do vendors of these iscsi devices
set their own acceptable ranges based on the RFC or is it not
standard?
Vendors will a lot of times recommend their preferred values.
If those are the only log messages you are seeing then the iscsi
timeouts are not coming into play. If you see iscsi nop/ping errors then
you would want to change the noop values. There are some general
guidlines for setting those and the scsi cmd timeout in the current
iscsi readme in here:
http://kernel.org/pub/linux/kernel/people/mnc/open-iscsi/releases/open-iscsi-2.0-872.tar.gz
If you are seeing only those messages you mentioned when you do the
partition and mkfs test then the scsi commands could be timing out. You
could turn on iscsi debugging
echo 1 > /sys/module/libiscsi/paramters/debug_libiscsi_eh
then run your fdisk/mkfs test and then send the logs. If a scsi command
is timeout you would want to increase that timer
(/sys/block/sdX/device/timeout - there is info on it in the README).
iscsiadm -m node -T iqn.2010.09.maxtronic.com:732af838098e3a24:ist1 |
grep timeout :
node.session.timeo.replacement_timeout = 120
node.session.err_timeo.abort_timeout = 15
node.session.err_timeo.lu_reset_timeout = 20
node.session.err_timeo.host_reset_timeout = 60
node.conn[0].timeo.logout_timeout = 15
node.conn[0].timeo.login_timeout = 15
node.conn[0].timeo.auth_timeout = 45
node.conn[0].timeo.noop_out_timeout = 10
thank you for any suggestions
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
