We've run into some issues in the past with iSCSI disconnects. As an FYI, one thing that has helped is is to put dm-multipath in the middle and add another iface. This allows one path to fail and you still get access to the device. I know it doesn't necessarily answer your question, but may help you in the future to help reduce the visibility of the problem. Additionally, dm-multipath will offer to queue_if_no_path, which will allow _some_ amount of SCSI commands to be queued in the event that there are no paths available. This has also helped us.
=========================== Joseph R. Hoot Lead System Programmer/Analyst [email protected] GPG KEY: 7145F633 =========================== On Feb 23, 2010, at 3:04 PM, Jonathan Murray wrote: > I am using iscsi to connect a Centos 5.2 server to a Promise Tech Vtrak > M610i > > On the linux box, I have > > iscsi-initiator-utils-6.2.0.868-0.18.el5 > 2.6.18-92.1.13.el5.centos.plus #1 SMP Wed Oct 1 13:41:35 EDT 2008 x86_64 > x86_64 x86_64 GNU/Linux > > The Promise array is on a separate subnet from the linux host. > > service iscsi start > > iscsiadm --mode discovery --type sendtargets --portal 128.128.181.69 -I > iface1 > iscsiadm --mode node iqn.1994-12.com.promise.dd.64.55.55.1.0.0.20 > --portal 128.128.181.69 --login > > and then the drives are mountable: > > Feb 22 11:13:22 ndsfdh1 kernel: iscsi: registered transport (tcp) > Feb 22 11:13:22 ndsfdh1 kernel: iscsi: registered transport (iser) > Feb 22 11:13:22 ndsfdh1 iscsid: iSCSI logger with pid=28337 started! > Feb 22 11:13:23 ndsfdh1 iscsid: transport class version 2.0-724. iscsid > version 2.0-868 > Feb 22 11:13:23 ndsfdh1 iscsid: iSCSI daemon with pid=28338 started! > Feb 22 11:14:43 ndsfdh1 iscsid: received iferror -38 > Feb 22 11:14:43 ndsfdh1 iscsid: connection1:0 is operational now > > we have a dedicated interface for iscsi traffic, contents of > /var/lib/iscsi/ifaces/iface1 > > iface.transport_name = tcp > iface.hwaddress = 00:1D:09:2F:15:B2 > > after about 24 hours, we see the following in /var/log/messages (not in > order) > > iscsid: connect failed (111) > iscsi: cmd 0x28 is not queued (8) > iscsi: cmd 0x2a is not queued (8) > iscsi: detected conn error (1011) > Kernel reported iSCSI connection 1:0 error (1011) state (3) > iscsid: connect failed (113) > > The only way to get the drives remounted is to shut down iscsi service > and then reboot the array and restart the iscsi service and remount. > > I have read on other threads there are other versions of the iscsi > software, like open-iscsi as opposed to iscsiadm and such. If there are > better packages or if I need additional software to make this connection > more reliable, I am open to suggestions. I am new to using the iscsi > protocol. > > Directly connected, the array worked fine with no errors (10.0.0.1 / > 10.0.0.2 network setup) > > One theory we have is that there is a 100 MB switch somewhere between > the linux box and the array that we don't know about. > > Any suggestions for troubleshooting this issue would be appreciated. > > thank you, > > > Jonathan Murray > Woods Hole Oceanographic > > > > > -- > 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. > -- 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.
