Description of problem: Setup: Two targets are connected to MDS. One of which is available only if the other is removed permanently(a dynamic target is created). The MDS is connected to the initiator. Problem: After removing the first iscsi target only the dynamic target is sent to the initiator on a SendTargets respose. So it sets up a session for the new target. But the older session (stale session) still remains and login is unecessarily retried on a permanently removed target. Version-Release number of selected component (if applicable): How reproducible: Always. Steps to Reproduce: 1. Make sure that all targets and iSCSI sessions are up. 2. Remove the target on MDS 3. Check the iSCSI sessions on the initiator. Actual results: The initiator tries to login into a permanently removed target. It does not tear down the older sessions. Expected results: The initiator should tear down all the old sessions, once the new dicovery responds with dissimilar targets. Additional info:
Created attachment 122443 [details] Fix for the bug
If the session just happens to be down temporarily when the iscsd is rerun won't this kill the session accidentally?
I believe the fix was the initiator would only tear down old sessions if the target returns with "target no longer exists". If target replies with "target error" then the initiator can continue retrying.
connet #2 by me should actually ne in the RHEL4 bugzilla entry. sorry about that.
This issue is on Red Hat Engineering's list of planned work items for the upcoming Red Hat Enterprise Linux 3.8 release. Engineering resources have been assigned and barring unforeseen circumstances, Red Hat intends to include this item in the 3.8 release.
This bug is filed against RHEL 3, which is in maintenance phase. During the maintenance phase, only security errata and select mission critical bug fixes will be released for enterprise products. Since this bug does not meet that criteria, it is now being closed. For more information of the RHEL errata support policy, please visit: http://www.redhat.com/security/updates/errata/ If you feel this bug is indeed mission critical, please contact your support representative. You may be asked to provide detailed information on how this bug is affecting you.