Description of problem:
Redhat 6.9 client (also verified happens with 6.6) is lun-booted from network storage device A, so root filesystem is an iscsi device.
Issue discovery command "iscsiadm --mode discovery --type sendtargets --portal <ip address>" to new network storage device B causes Redhat to log out the connection to storage device A. Then there is a race for the Redhat client to iscsi re-login into device A before some amount of time expires (2 seconds?) and if the login doesn't happen in that time, the root filesystem becomes read-only.
Verified with Wireshark trace the RHEL client chooses to log out of the connection with device A when discovery command is issued with IP address of device B, and then a login operation immediately begins to reestablish the connection with device A.
Since this causes a service disruption I'm looking for a way to prevent the logout from device A when discovering luns on device B.
Version-Release number of selected component (if applicable):
RHEL 6.6 and 6.9
Steps to Reproduce:
1. Lun boot RHEL 6.9 using iSCSI lun on network storage device A
2. Issue iscsiadm sendtargets command to network storage device B
3. Observe iscsi connection to device A is terminated
4. Observe in a high number of instance the iscsi connection is not reestablished fast enough to prevent read-only root filesystem
Root filesystem becomes read-only and the client has to be rebooted.
Iscsi discovery to a storage device does not affect existing iscsi connections.
Reproduced with RHEL 6.10
Can you give me more details on the initiator configuration?
Is this with iscsi_tcp or with an iSCSI HBA?
If it's an HBA, which make/driver?
Are the two targets on the same network, or different networks?
Does it reproduce without booting from iSCSI?
Can you share a network trace that shows the logout?
How about the iSCSI configuration from /var/lib/iscsi?
My initial attempts to reproduce this failed, in that I did not see this behavior.
Created attachment 1446312 [details]
Network trace and iscsi configuration data
Answering Chris Leech questions:
* This is with iscsi_tcp
* The two targets are on different networks
* I don't have a way to reproduce without booting from iSCSI
* I have attached an attachment with network trace and files from /var/lib/iscsi