Red Hat Bugzilla – Bug 251965
"iscsiadm: encountered connection failure - error 4" during boot up.
Last modified: 2010-10-22 13:29:31 EDT
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
Version-Release number of selected component (if applicable):
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.
You see the error occur during boot. The NIC script run before the iSCSI
initiator script does, however you still get a connection error.
The initiator is supposed to successfully log in to the target during boot up.
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
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
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
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
Move to 5.5. The default is pretty high now, so we have not got any reports of people still hitting this.