Bug 652730 - Never forgets iscsi sessions & silently logs back in upon network activation
Never forgets iscsi sessions & silently logs back in upon network activation
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt (Show other bugs)
6.1
All Linux
low Severity medium
: rc
: ---
Assigned To: Daniel Veillard
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-11-12 11:31 EST by Daniel Berrange
Modified: 2011-05-19 09:23 EDT (History)
13 users (show)

See Also:
Fixed In Version: libvirt-0.8.7-3.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 643092
Environment:
Last Closed: 2011-05-19 09:23:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Daniel Berrange 2010-11-12 11:31:27 EST
+++ This bug was initially created as a clone of Bug #643092 +++

Description of problem:
Every time i resume from suspend, previous iscsi session I've logged out off, get re-activated.

AFAICT, the iscsi initiator saves details of the iSCSI target in /var/lib/iscsi/nodes. Whenever network manager activates an interface (eg resuming from suspend), /etc/init.d/iscsi will login to any targets listed in /var/lib/iscsi/nodes, even if they were *not* logged into previously.

eg, 

[root@t500wlan ~]# iscsiadm -m session
iscsiadm: No active sessions.
[root@t500wlan ~]# find /var/lib/iscsi/nodes/
/var/lib/iscsi/nodes/
[root@t500wlan ~]# /sbin/iscsiadm --mode discovery --type sendtargets --portal 192.168.254.185:3260,1
192.168.254.185:3260,1 iqn.2004-04.com.qnap:ts-439proii:iscsi.berrangehome.bf6d84
[root@t500wlan ~]# /sbin/iscsiadm --mode node --portal 192.168.254.185:3260,1 --targetname iqn.2004-04.com.qnap:ts-439proii:iscsi.berrangehome.bf6d84 --loginLogging in to [iface: default, target: iqn.2004-04.com.qnap:ts-439proii:iscsi.berrangehome.bf6d84, portal: 192.168.254.185,3260]
Login to [iface: default, target: iqn.2004-04.com.qnap:ts-439proii:iscsi.berrangehome.bf6d84, portal: 192.168.254.185,3260] successful.
[root@t500wlan ~]# find /var/lib/iscsi/nodes/
/var/lib/iscsi/nodes/
/var/lib/iscsi/nodes/iqn.2004-04.com.qnap:ts-439proii:iscsi.berrangehome.bf6d84
/var/lib/iscsi/nodes/iqn.2004-04.com.qnap:ts-439proii:iscsi.berrangehome.bf6d84/192.168.254.185,3260,1
/var/lib/iscsi/nodes/iqn.2004-04.com.qnap:ts-439proii:iscsi.berrangehome.bf6d84/192.168.254.185,3260,1/default
[root@t500wlan ~]# iscsiadm -m session
tcp: [10] 192.168.254.185:3260,1 iqn.2004-04.com.qnap:ts-439proii:iscsi.berrangehome.bf6d84
[root@t500wlan ~]# /sbin/iscsiadm --mode node --portal 192.168.254.185:3260,1 --targetname iqn.2004-04.com.qnap:ts-439proii:iscsi.berrangehome.bf6d84 --logout
Logging out of session [sid: 10, target: iqn.2004-04.com.qnap:ts-439proii:iscsi.berrangehome.bf6d84, portal: 192.168.254.185,3260]
Logout of [sid: 10, target: iqn.2004-04.com.qnap:ts-439proii:iscsi.berrangehome.bf6d84, portal: 192.168.254.185,3260] successful.
[root@t500wlan ~]# iscsiadm -m session
iscsiadm: No active sessions.
[root@t500wlan ~]# /etc/init.d/iscsi start
Starting iscsi:                                            [  OK  ]
[root@t500wlan ~]# iscsiadm -m session
tcp: [11] 192.168.254.185:3260,1 iqn.2004-04.com.qnap:ts-439proii:iscsi.berrangehome.bf6d84

It absolutely should *NOT* have activated the session in that last step, since I had explicitly logged out of the iscsi session.


Version-Release number of selected component (if applicable):
iscsi-initiator-utils-6.2.0.872-7.fc13.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Login to an iscsi session
2. Logout of the iscsi session
3. /etc/init.d/iscsi start
  
Actual results:
It activates sessions that were logged out of

Expected results:
Logged out sessions, remain logged out.

Additional info:

--- Additional comment from berrange@redhat.com on 2010-10-14 11:45:42 EDT ---

Created attachment 453499 [details]
Clearer log of the command sequence to demonstrate problem

Bugzilla munged the line endings in the initial description. Attached a clearer copy of the command sequence.

--- Additional comment from mchristi@redhat.com on 2010-10-14 16:25:00 EDT ---

/etc/init.d/iscsi start logs into all portals with the node.startup = automatic. If instead of that script controlling startup, you should mark the startup = manual.

If that does not help or what you were looking for, then we need something completely different, because this is just how the tools/daemon/script work. The iscsiadm login/logout command just tells the kernel to login/logout a sessions it does not control the /etc/init.d/iscsi script's startup behavior. And normally if you were to logout a session with iscsiadm then ran /etc/init.d/iscsi start, users expect the node.startup setting to indicate that the session should be logged in (users use the script to log into the sessions instead of running iscsiadm).

--- Additional comment from mchristi@redhat.com on 2010-10-14 16:26:49 EDT ---

Oh yeah, to set the startup you can edit /etc/iscsi/iscsid.conf's node.startup, then rediscover the iscsi portals (when you discover the portals the new iscsid.conf setttings get picked up).

Or run iscsiadm to set the node.startup for existing records

iscsiadm -m node -o update -n node.startup -v manual

--- Additional comment from berrange@redhat.com on 2010-10-15 06:04:10 EDT ---

IMHO startup = manual should be the default here. Merely running iSCSI sendtargets should not be causing the host to automatically login to the targets forever after, unless the admin explicitly asked for that behaviour.

--- Additional comment from mchristi@redhat.com on 2010-10-16 18:53:15 EDT ---

(In reply to comment #4)
> IMHO startup = manual should be the default here. Merely running iSCSI
> sendtargets should not be causing the host to automatically login to the
> targets forever after, unless the admin explicitly asked for that behaviour.

They do try to login forever though. They login for whatever your initial login retries and timeouts are set at.

Also normally users set things up on the target so only the targets that are accessible to the initiator are returned in sendtargets discovery. So every target returned during discovery is one they want to log into (this is why the default for startup is automatic).

--- Additional comment from mchristi@redhat.com on 2010-10-16 18:58:11 EDT ---

(In reply to comment #5)
> (In reply to comment #4)
> > IMHO startup = manual should be the default here. Merely running iSCSI
> > sendtargets should not be causing the host to automatically login to the
> > targets forever after, unless the admin explicitly asked for that behaviour.
> 
> They do try to login forever though. They login for whatever your initial login
> retries and timeouts are set at.
> 

Ignore that part of the comment above. I thought you meant something different.

--- Additional comment from berrange@redhat.com on 2010-11-12 11:28:39 EST ---

In a SOHO environment where people are using something like a Netgear/QNap NAS to provide iSCSI, it is far less likely that the target list will be zoned per client machine. In any case, I've added code to libvirt to force node.startup=manual everytime 'sendtargets' is run to work about this debatable behaviour.

--- Additional comment from berrange@redhat.com on 2010-11-12 11:29:09 EST ---

Patch series upstream

http://www.redhat.com/archives/libvir-list/2010-November/msg00545.html
Comment 1 Daniel Veillard 2011-01-23 23:27:18 EST
This should be in as part of the rebases to 0.8.6 and 0.8.7,

Daniel
Comment 3 Nan Zhang 2011-03-04 04:46:59 EST
Verified with libvirt-0.8.7-8.el6.x86_64, it's fixed already. Move to VERIFIED.


# virsh pool-define iscsi-pool.xml 
Pool test-iscsi defined from iscsi-pool.xml

# virsh pool-start test-iscsi
Pool test-iscsi started

# virsh pool-list
Name                 State      Autostart 
-----------------------------------------
test-iscsi           active     no        

# virsh pool-dumpxml test-iscsi
<pool type='iscsi'>
  <name>test-iscsi</name>
  <uuid>93948350-6b5e-a6aa-bf63-bbf472d903b1</uuid>
  <capacity>250000000000</capacity>
  <allocation>250000000000</allocation>
  <available>0</available>
  <source>
    <host name='10.66.90.115'/>
    <device path='iqn.1992-08.com.netapp:sn.135053389'/>
  </source>
  <target>
    <path>/dev/disk/by-path</path>
    <permissions>
      <mode>0700</mode>
      <owner>-1</owner>
      <group>-1</group>
    </permissions>
  </target>
</pool>

# iscsiadm -m session
tcp: [3] 10.66.90.115:3260,1000 iqn.1992-08.com.netapp:sn.135053389
# virsh pool-destroy test-iscsi
Pool test-iscsi destroyed

[root@dhcp-93-181 ~]# iscsiadm -m session
iscsiadm: No active sessions.
Comment 6 errata-xmlrpc 2011-05-19 09:23:57 EDT
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-2011-0596.html

Note You need to log in before you can comment on or make changes to this bug.