Persistent connections across initiator reboot
I discovered 2 machine,192.168.7.50(containing 10 targets,out of which performed login on 2) and 192.168.7.51(containing 5 targets,out of which performed login on 3).I am using IET target and 'iscsi-initiator- utils-6.2.0.868-0.7.el5' initiator. So at present there are 5 connections on initiator.suddenly if initiator reboots. we are having following code in 'iscsi' service iscsiadm -m node --logoutall=all(stop function) iscsiadm -m node --loginall=automatic(start function) But disadvantage is that it will login to all 15 targets from both 7.50 and 7.51 machines,and not 5 which already were there.This is because previous discovery entry is still there in /var/lib/iscsi/ nodes and /var/lib/iscsi/send_targets. If I commented above 2 lines from 'iscsi' service,It works fine for stop,start,restart service operations.i.e.initiator is restoring only connections which were there previously. But this doesn't work across reboot.I lost my 5 connections after reboot though above 2 lines were commented. Thus,what should I do for persistent connections across reboot? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: Advice on device recovery
On 17 Apr 2009 at 15:22, dave wrote: Long post, but please bear with me :) This post is related to my previous post at: http://groups.google.com/group/open-iscsi/browse_thread/thread/4569bc674383145a/e6c2e4320ec401f5?lnk=gstq=device+not+ready#e6c2e4320ec401f5 My situation: I have linux initiators running open-iscsi 2.0-869 with dm-multipath, queue_if_no_path enabled. The target is an OpenSolaris box sharing zvols from a mirrored zpool, which means the target LUNs are virtual devices with storage backed by the ZFS zpool. The problem: When one of the disks in the solaris zpool dies, ZFS halts reads/ writes to the zpool for a minute or two while it waits for the disk controller/driver to determine if the device should be offlined. The side effect of this is that because the iSCSI targets are virtual devices with their data store being the ZFS zpool, the iSCSI read/ writes are also halted as long as ZFS is waiting for a device to fail. The iSCSI targets don't disappear, they are just unable to complete read/write ops - they still respond fine to logins and target discovery. Once ZFS continues operation, the iSCSI devices also resume normal operation. Since I am using multipath on the linux initiators, the linux boxes can wait patiently for read/writes to resume, but it seems that the scsi system does not retry TUR messages which can cause the device to never be put back into operation on the initiator node. Hi! I guess the TUR are queued, just as any other SCSI command. Thus the TURs will be processed after your virtual LUNs did recover. This brings up an issue I was thinking about already: Does it make any sense for mutipath to run a path checker, wehen there was regular traffic (command/response) recently? Likewise, (I don't know if iopen-iscsi does that) does it make sense to send No-Ops to a target if the target had sent a reply recently? I'm seeing quite busy switch ports, een if the iSCSI data traffic is expected to be very low. With 16 paths per LUN here, frequent probing by multipath and open- iscsi would be one explanation. [...] Regards, Ulrich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: Persistent connections across initiator reboot
On 20 Apr 2009 at 2:46, HIMANSHU wrote: I discovered 2 machine,192.168.7.50(containing 10 targets,out of which performed login on 2) and 192.168.7.51(containing 5 targets,out of which performed login on 3).I am using IET target and 'iscsi-initiator- utils-6.2.0.868-0.7.el5' initiator. So at present there are 5 connections on initiator.suddenly if initiator reboots. we are having following code in 'iscsi' service iscsiadm -m node --logoutall=all(stop function) iscsiadm -m node --loginall=automatic(start function) Wouldn't your problem be solved if you set some of the automatic connections to manual? But disadvantage is that it will login to all 15 targets from both 7.50 and 7.51 machines,and not 5 which already were there.This is because previous discovery entry is still there in /var/lib/iscsi/ nodes and /var/lib/iscsi/send_targets. [...] Ulrich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: Data Digest - Unit Attention Problem
A few more comments on this failure: This may be a problem with how the check response is being processed by the iSCSI stack...possibly due to data digest. The Inquiry command goes out, the response is received with data digest, and appears to be accepted. A Test Unit Ready command then goes out, response received, and 500 ms later the initiator attempts to open a new connection/login. The target then resets the original TCP connection. This is repeated several times Is it possible that the check response with data digest is not being handled correctly? The /var/log/message contains a series of the following messages: connection2:0:0 detected conn error (1011) On Apr 17, 9:17 am, Joer jre...@yahoo.com wrote: I ran into an odd interaction between having Data Digest enabled for a session and the classic Unit Attention check condition for the first command issued during a session other than Inquiry. My base setup is as follows: Open iSCSI Initiator: 2.0-869.2 RHEL 5.2 32 bit running in an ESX VM My test has four target entities behind a dual portal -portal group. The targets are setup to negotiate digest as follow: Target1: no header digest / no data digest Target2: no header digest / data digest Target3: header digest / no data digest Target4: header digest / data digest The problem: Open iSCSI posts a connection error and resets the connection when the Unit Attention check condition is received on Targets 2 and 4 following a Test Unit Ready command. My first guess was that there was a problem with Data Digest generated by for the response PDU containing the check. However, the Wireshark capture performed on the nitiator side is saying the digest is good. I checked the response PDU format and padding and it looks correct. Has anyone seen anything like this before? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: Persistent connections across initiator reboot
HIMANSHU wrote: I discovered 2 machine,192.168.7.50(containing 10 targets,out of which performed login on 2) and 192.168.7.51(containing 5 targets,out of which performed login on 3).I am using IET target and 'iscsi-initiator- utils-6.2.0.868-0.7.el5' initiator. So at present there are 5 connections on initiator.suddenly if initiator reboots. we are having following code in 'iscsi' service iscsiadm -m node --logoutall=all(stop function) iscsiadm -m node --loginall=automatic(start function) But disadvantage is that it will login to all 15 targets from both 7.50 and 7.51 machines,and not 5 which already were there.This is Do you have only the target records you want to log into automatically marked as node.startup=automatic? because previous discovery entry is still there in /var/lib/iscsi/ nodes and /var/lib/iscsi/send_targets. I didn't follow you when you meantioned the previous entry. Are you running the iscsiadm discovery command at some point during startup? If I commented above 2 lines from 'iscsi' service,It works fine for stop,start,restart service operations.i.e.initiator is restoring only connections which were there previously. Aare you running a custom script that logs into specific targets or how do you log into targets if the init script does not run loginall=automatic? But this doesn't work across reboot.I lost my 5 connections after reboot though above 2 lines were commented. Thus,what should I do for persistent connections across reboot? I think you just want to set the targets you want to log into with the node.startup = automatic. When that loginall=automatic gets run, it will only log into those targets. iscsiadm -m node -T target -p ip:port -o update -n node.startup -v startup I think with IET you can set up lists to control how can log into which target. Does that work for you? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: Data Digest - Unit Attention Problem
Joer wrote: A few more comments on this failure: This may be a problem with how the check response is being processed by the iSCSI stack...possibly due to data digest. The Inquiry command goes out, the response is received with data digest, and appears to be accepted. A Test Unit Ready command then goes out, response received, and 500 ms later the initiator attempts to open a new connection/login. The target then resets the original TCP connection. This is repeated several times Is this easy to replicated? Does it happen every time? Were you using the initiator that comes with RHEL 5.2 or 2.0-869.2 from open-iscsi.org? Is it possible that the check response with data digest is not being handled correctly? The /var/log/message contains a series of the following messages: connection2:0:0 detected conn error (1011) Do you see any 1015 errors? 1015 is for data digest errors. 1011 is generic connection problems or cases where we dropped it for some generic reason. Is there anything else in the log? Something about a ping or nop timing out? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
