Description of problem: iscsiadm is reporting an error code 4 (encountered connection failure) during boot. We think it is because of the order/speed of which the NIC being brought online. Version-Release number of selected component (if applicable): How reproducible: Every time. Steps to Reproduce: 1. Establish a discovery session and log into the target. 2. Get a list of volumes from the target. 3. Reboot the host. Actual results: You see the error occur during boot. The NIC script run before the iSCSI initiator script does, however you still get a connection error. Expected results: The initiator is supposed to successfully log in to the target during boot up. Additional info: You can create a normal session with the target after the host has completely booted up. The connection problem only occurs while the host is coming online.
Could you try the 5.1 beta? Also what NIC is this with? Did I ask this before? There are is a bug where the network layer or a NIC is reporting that everything is ready to go, but it is not, so when we get to the iscsi startup we cannot log in because the network is not up. In 5.1 I added a wait and retry to the iscsi startup to work around network issues and transient errors.
We've retested with the latest 5.1 beta and on a reboot auto login still fails.
Could you run iscsid with -d 8 and send the log output?
ignore that last request. It is going to be a pain for you to do that.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
This request was previously evaluated by Red Hat Product Management for inclusion in the current Red Hat Enterprise Linux release, but Red Hat was unable to resolve it in time. This request will be reviewed for a future Red Hat Enterprise Linux release.
LSI, are you using DHCP or static ips on the initiator side?
Static IPv4 addresses.
Ok, try increasing node.session.initial_login_retry_max to 15 or 30.
Neither of those values worked. I see the connection failures, however all of the sessions appear to come up correctly. With RHEL5 U1, this issue seems to be just a cosmetic issue now.
(In reply to comment #10) > Neither of those values worked. I see the connection failures, however all of > the sessions appear to come up correctly. You lost me :) Do you see connection failures from iscsid, but iscsiadm ends up connecting so you see iscsiadm return a message that the session was established eventually?
Sorry for the long delay in my reply. I finally got around to re-examining this issue and found it to be completely fixed in RHEL5 U1. Comment #10 was in regards to the other iSCSI host ports that are not plugged in, but still have an IP address (array defaults to a 192.168.x.x address if not configured). Our arrays will send all target information in the text response of a "send targets" command, and this was what I was seeing time out. I did not have to adjust the node.session.initial_login_retry_max value.
I noticed a similar problem with root iscsi on a xen domU, if the bridge's forward delay setting is higher than the timeout that iscsistart uses. I guess this "bug" belongs to anaconda?
(In reply to comment #13) > I noticed a similar problem with root iscsi on a xen domU, if the bridge's > forward delay setting is higher than the timeout that iscsistart uses. I guess > this "bug" belongs to anaconda? I do not think anaconda is going to do anything for this. You have to set the timeout higher yourself. I actually increased it to over two minutes (we allow something like 120 retries) for 5.2. For RHEL 5.3 I can make it so we can configure this if you are still having troubles.
Move to 5.5. The default is pretty high now, so we have not got any reports of people still hitting this.