Bug 192462

Summary: [EMC/NetApp/Oracle RHEL 4.7 bug] Cannot specify ports to use with iscsi tools in RHEL4
Product: Red Hat Enterprise Linux 4 Reporter: Mike Christie <mchristi>
Component: iscsi-initiator-utilsAssignee: Mike Christie <mchristi>
Status: CLOSED ERRATA QA Contact: Alexander Todorov <atodorov>
Severity: high Docs Contact:
Priority: high    
Version: 4.0CC: andriusb, bdonahue, berthiaume_wayne, coughlan, cward, davidw, emcnabb, greg.marsden, josh, kearnan_keith, marcobillpeter, tao
Target Milestone: ---Keywords: OtherQA
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: RHBA-2008-0743 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-07-24 19:59:59 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:
Bug Depends On:    
Bug Blocks: 241692, 246627, 252336, 367631    
Attachments:
Description Flags
black/white list portals
none
Turn off specific portals during startup none

Description Mike Christie 2006-05-19 20:07:30 UTC
Description of problem:

If a port is not accessable or if the user does not want to use for whatever
reason, there is no way to tell the driver not to use it. Today, if the port is
not accessable the driver will detect this and not try to login, but if I just
did not want to use the port we have to login then use the iscsi session
shutdown tool to remove it which is a pain in the butt.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Andrius Benokraitis 2006-05-24 20:53:15 UTC
This bug is a continuation of bug 182684 that was partly implemented in RHEL
4.4. This bug is to be tracked for RHEL 4.5 by multiple partners that are asking
for this.

Comment 13 Andrius Benokraitis 2007-01-08 18:28:21 UTC
Deferred to RHEL 4.6 per discussions with Mike Christie.

Comment 14 RHEL Program Management 2007-03-10 01:06:00 UTC
This bugzilla had previously been approved for engineering
consideration but Red Hat Product Management is currently reevaluating
this issue for inclusion in RHEL4.6.

Comment 15 RHEL Program Management 2007-05-09 10:21:59 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 25 Wayne Berthiaume 2007-08-21 14:30:30 UTC
This continues to be a sore spot with our customers and CS continues to receive 
calls about it. Will this be resolved in RHEL 4.6?

Comment 27 Mike Christie 2007-08-21 15:59:09 UTC
(In reply to comment #26)
> EMC are insisting we get this fixed in 4.6 based upon the comments above and the
> following e-mail we received from EMC.  Flagging exception for this issue to
> request it goes in post-beta.
> 
> 
> > "We continue to receive calls and complaints from our customers
> > both externally and internally on the error messages


What error messages are you they referring to? We fixed the issue of retry/login
error messages filling up the log back in 4.5 or 4.6. We now try to login into
the portal 5 times. If we cannot log in we spit out a error message, but after 5
times we give up. We do not retry the login forever and fill up the log like in
4.4. There is also a modparam that can be used to control the retries.



Comment 28 Mike Christie 2007-08-21 16:05:35 UTC
(In reply to comment #27)
> (In reply to comment #26)
> > EMC are insisting we get this fixed in 4.6 based upon the comments above and the
> > following e-mail we received from EMC.  Flagging exception for this issue to
> > request it goes in post-beta.
> > 
> > 
> > > "We continue to receive calls and complaints from our customers
> > > both externally and internally on the error messages
> 
> 
> What error messages are you they referring to? We fixed the issue of retry/login
> error messages filling up the log back in 4.5 or 4.6. We now try to login into

this was fixed in 4.5.

> the portal 5 times. If we cannot log in we spit out a error message, but after 5
> times we give up. We do not retry the login forever and fill up the log like in
> 4.4. There is also a modparam that can be used to control the retries.
> 

Oh yeah, just to be clear. I am not saying that the fix we did in 4.5 allows you
to configure which ports you want to use or not. The major problem we had was
that the login code would try to login into ports forerver, and each time the
login failed it would spit an error message so the log would be filled.

For 4.5 we fixed that by doing the RHEL3 and RHEL5 behavior where we try to
login X times. If that fails we give up. This has fixed the issue where
customers just want to run the initiator and not worry about configuration, but
before they were seeing the log fill up, but in RHEL3 and RHEL5 they did not.


The second issue is allowing people that want to configure there boxes to be
able to do so like in RHEL5. I am working on a patch. It is invassive. It is a
userspace code only patch. I am trying to see if we can squeeze it in or if I
can make it less invassive.

Comment 29 Wayne Berthiaume 2007-08-21 17:06:38 UTC
True, the number of the error messages has decreased in RHEL 4.5 but the 
message still catches their eye. Believe me, I understand the level of work 
involved in making this change and am not taking it lightly.

Comment 30 Mike Christie 2007-08-21 17:48:36 UTC
(In reply to comment #29)
> True, the number of the error messages has decreased in RHEL 4.5 but the 
> message still catches their eye.

Yeah, I agree with that, but RHEL5 spits out error messages too though. And it
seems a lot of your users are not turning off the portals manually. Instead they
just use the default setup which behaves like RHEL 4.5. RHEL5 is not as verbose
as RHEL 4.5 though. But most users get tripped on setting the startup value so
we have the default startup method as automatic instead of manual (which is the
opposite from upstream and some other distros). Are you guys not seeing any
complaints about RHEL5's error messages too?

Comment 31 Mike Christie 2007-08-21 17:49:49 UTC
If you see complaints for both RHEL4 and RHEL5 I can change both behaviors so
they are the same and do not confuse users.

Comment 32 Mike Christie 2007-08-21 18:02:32 UTC
(In reply to comment #31)
> If you see complaints for both RHEL4 and RHEL5 I can change both behaviors so
> they are the same and do not confuse users.

Oh yeah, I do not mean I will not do the portal blacklist stuff. I just mean I
will fix both.

Comment 33 Wayne Berthiaume 2007-08-22 12:53:59 UTC
We use automatic for RHEL 5 so the filesystems can be mounted at boot. The only 
complaint that has been floated in my direction is the inconsistency in getting 
targets logged in automatically. It appears that some times the targets are not 
logged in most likely due to the NIC not being ready because a sleep() added in 
the start stanza of the init script seems to mitigate this issue. But this is a 
seperate issue from this BZ's subject matter.

Comment 34 Mike Christie 2007-08-24 02:35:59 UTC
Created attachment 172388 [details]
black/white list portals

The attached patch was made over the current RHEL 4.6 source which can be found
here
http://people.redhat.com/mchristi/iscsi/RHEL4/u6/

The patch is the least invasive approach I could think of.

Currently we can disable/enable whole targets with the TargetName keyword. We
can also set config values at the Subnet/Address level using those keywords, so
I just slipped in support to handle enable/disbale at the Subnet/Address level.


To disable a portal you do:

Address=192.168.0.11
   Enabled=no

To disable a bunch of portals do:

Subnet=10.4.100.0/24
  Enabled=no

Never bug me about this bugzilla again :) Andrius and Tom can I get an
exception + so I can slip this into 4.6?

Comment 35 Mike Christie 2007-08-24 02:57:42 UTC
Oh yeah, because I did a really simple fix, it means that for a setup where you
have a portal on multiple targets but just want to disable access for one target
you are out of luck. Having a portal on multiple targets will be more rare but
targets like equalogic do this. We can add support for that in 4.7 when there is
more time if anyone wants that functionality.

Comment 39 Mike Christie 2007-09-25 18:54:16 UTC
After talking to some of you guys some more, I am not going to merge the simple
fix. Instead for 4.7, I am going to finish up the more complicated bits, test
everything together and then it will all be done. And you can never bug me about
it then :)

Comment 41 RHEL Program Management 2007-11-29 04:25:45 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 42 Mike Christie 2008-04-11 20:08:51 UTC
Created attachment 302166 [details]
Turn off specific portals during startup

The patch allows you do disable/enable a specific portal on a target. You can
do this in the iscsi.conf file like so:

# To enable/disable a portal on a specific target, use the following entry
#TargetName=iqn.1987-05.com.cisco:00.0d1d898e8d66.t0
#	Address=192.168.0.10
#		Enabled=no

This fits in with how we currently allow you to enable/disable an entire target
by doing:

#TargetName=iqn.1987-05.com.cisco:00.0d1d898e8d66.t0
#		Enabled=no

Comment 44 Andrius Benokraitis 2008-04-30 21:08:00 UTC
Mike - has this been committed? I don't see this on MODIFIED yet...

Comment 46 Alexander Todorov 2008-05-05 06:57:36 UTC
Things to test (from comment #43):

1. Setup a target with multiple portals, and set
TargetName=iqn.1987-05.com.cisco:00.0d1d898e8d66.t0
      Address=192.168.0.10
           Enabled=no

for one of them. Instead of logging into both portals like normal, we shuold
only log into the one that is not set above.

2. User IET or tgt to define multiple targets. By default IET will only setup
one portal, but all the targets come from the same discovery source. So set up
one of the targets to be disabled by doing:

TargetName=iqn.1987-05.com.cisco:00.0d1d898e8d66.t0
      Address=192.168.0.10
           Enabled=no

3. Setup some global portal settings mixed with the target specific ones. So do

Address=192.168.0.10
     Enabled=no

TargetName=iqn.1987-05.com.cisco:00.0d1d898e8d66.t0
      Address=192.168.0.10
           Enabled=yes

For this setting, if you had two targets using 192.168.0.10, like with #2, then
the target with with the name
TargetName=iqn.1987-05.com.cisco:00.0d1d898e8d66.t0 should get logged into while
the other ones should not.


Comment 53 Chris Ward 2008-06-18 14:58:36 UTC
This **High Priority** bug should have been fixed since the latest RHEL4U7 Beta
release, available on RHN today. 

Please update this bugzilla with the latest test results confirming the bug has
been fixed or remains an issue. 

Thanks!


Comment 55 Andrius Benokraitis 2008-06-19 12:53:28 UTC
Wayne @ EMC: Can this get tested?

Comment 56 Wayne Berthiaume 2008-06-19 21:35:03 UTC
Hi Andrius.

    I already have a server that is in position to test this. 

Regards,
Wayne.

Comment 57 Chris Ward 2008-06-27 11:37:58 UTC
~ Attention ~ Testing Feedback Deadlines are approaching!

This bug should fixed in Partner Snapshot 4, which is now available on
partners.redhat.com, ready for testing.

We are approaching the end of RHEL 4.7 testing cycle. It is important to let us
know of your testing results *as soon as possible*. If any issues are found once
the testing phase  deadline has passed, you might lose your opportunity to
include the fix in this RHEL update.

If you have verified that this bug has been properly fixed or have discovered
any issues, please provide detailed feedback of your testing results, including
the package version   and snapshot tested. The bug status will be updated for
you, based on testing results.

Contact your Partner Manager with any additional questions.


Comment 58 Andrius Benokraitis 2008-06-27 15:11:22 UTC
Wayne at EMC hit a possible problem with snapshot 2, but will try snapshot 4
shortly.

Comment 59 Alexander Todorov 2008-06-30 14:38:48 UTC
ping,
any update here? snap #4 has been public for around a week now.

Comment 60 Barry Donahue 2008-07-01 20:50:05 UTC
I created a series of scripts to create 512 volumes on our euqallogic array. I
ran on the RHEL4-U7-re20080625.0 build. The iscsi build was
iscsi-initiator-utils-4.0.3.0-7. The system was able to log in to all the
targets and then successfully shut down all the targets.

Comment 61 Barry Donahue 2008-07-01 20:51:39 UTC
Ignore last comment. Wrong bug.

Comment 62 Wayne Berthiaume 2008-07-09 14:02:15 UTC
In test with Snapshot 5.

Comment 66 Chris Ward 2008-07-14 09:57:14 UTC
Ping EMC, Wayne. Test results?

Comment 67 Chris Ward 2008-07-14 11:09:22 UTC
~ Final Notice ~ Testing Phase Ending Soon

This bug should have been fixed in the latest RHEL 4.7 Release Candidate,
available **now** on partners.redhat.com.

If you have already verified that this bug has been properly fixed or have found
any issues, please provide detailed feedback of your testing results, including
the package version and snapshot tested. The bug status will be updated for you,
based on the returned testing results.

Contact your Partner Manager with any additional questions.

Comment 70 Wayne Berthiaume 2008-07-15 14:46:34 UTC
The patch works as described in comment #46. However, one function we were 
trying to obtain was to associate the target with the initiator so you could 
further refine it to the point where a particular initiator (NIC) would not 
attempt to log into a particular target but the other one could log into that 
target. I believe this would be similar in function to the iface in open-iscsi.

Regards,
Wayne. 

Comment 72 errata-xmlrpc 2008-07-24 19:59:59 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2008-0743.html

Comment 73 Chris Ward 2008-07-29 07:31:18 UTC
Partners, I would like to thank you all for your participation in assuring the
quality of this RHEL 4.7 Update Release. My hat's off to you all. Thanks.