Bug 251965

Summary:	"iscsiadm: encountered connection failure - error 4" during boot up.
Product:	Red Hat Enterprise Linux 5	Reporter:	Fong Banh <fong.banh>
Component:	iscsi-initiator-utils	Assignee:	Mike Christie <mchristi>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	5.3	CC:	fabian.deutsch, jfeeney, jwest, k.georgiou, khtan, tao, wwlinuxengineering, yanqing_liu
Target Milestone:	---
Target Release:	5.5
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-02-02 19:40:19 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Fong Banh 2007-08-13 17:55:39 UTC

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.

Comment 1 Mike Christie 2007-09-05 16:57:01 UTC

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.

Comment 2 khtan 2007-09-06 16:13:53 UTC

We've retested with the latest 5.1 beta and on a reboot auto login still fails.

Comment 3 Mike Christie 2007-09-06 20:35:02 UTC

Could you run iscsid with -d 8 and send the log output?

Comment 4 Mike Christie 2007-09-06 21:10:11 UTC

ignore that last request. It is going to be a pain for you to do that.

Comment 5 RHEL Program Management 2007-12-06 21:44:38 UTC

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.

Comment 6 RHEL Program Management 2008-03-11 19:42:31 UTC

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.

Comment 7 Mike Christie 2008-03-11 20:15:55 UTC

LSI, are you using DHCP or static ips on the initiator side?

Comment 8 Fong Banh 2008-03-13 15:21:28 UTC

Static IPv4 addresses.

Comment 9 Mike Christie 2008-03-13 15:30:21 UTC

Ok, try increasing node.session.initial_login_retry_max
to 15 or 30.

Comment 10 Fong Banh 2008-03-14 13:40:19 UTC

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.

Comment 11 Mike Christie 2008-03-14 17:06:12 UTC

(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?

Comment 12 Fong Banh 2008-04-17 20:10:44 UTC

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.

Comment 13 Kostas Georgiou 2008-05-11 16:56:01 UTC

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?

Comment 14 RHEL Program Management 2008-06-02 20:33:52 UTC

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.

Comment 15 Mike Christie 2008-06-28 02:11:49 UTC

(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.

Comment 17 RHEL Program Management 2008-10-27 18:22:26 UTC

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.

Comment 18 Mike Christie 2009-06-13 02:29:46 UTC

Move to 5.5. The default is pretty high now, so we have not got any reports of people still hitting this.