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-utils | Assignee: | Mike Christie <mchristi> | ||||||
Status: | CLOSED ERRATA | QA Contact: | Alexander Todorov <atodorov> | ||||||
Severity: | high | Docs Contact: | |||||||
Priority: | high | ||||||||
Version: | 4.0 | CC: | 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
Mike Christie
2006-05-19 20:07:30 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. Deferred to RHEL 4.6 per discussions with Mike Christie. This bugzilla had previously been approved for engineering consideration but Red Hat Product Management is currently reevaluating this issue for inclusion in RHEL4.6. 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 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? (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. (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. 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. (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? If you see complaints for both RHEL4 and RHEL5 I can change both behaviors so they are the same and do not confuse users. (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. 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. 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? 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. 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 :) 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. 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
Mike - has this been committed? I don't see this on MODIFIED yet... 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. 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! Wayne @ EMC: Can this get tested? Hi Andrius. I already have a server that is in position to test this. Regards, Wayne. ~ 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. Wayne at EMC hit a possible problem with snapshot 2, but will try snapshot 4 shortly. ping, any update here? snap #4 has been public for around a week now. 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. Ignore last comment. Wrong bug. In test with Snapshot 5. Ping EMC, Wayne. Test results? ~ 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. 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. 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 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. |