Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.

Bug 967605

Summary: Cannot attach FC storage domain to RHEV when using QLogic iSCSI HBA offload card
Product: Red Hat Enterprise Virtualization Manager Reporter: Marina <mkalinin>
Component: vdsmAssignee: Federico Simoncelli <fsimonce>
Status: CLOSED ERRATA QA Contact: Aharon Canan <acanan>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 3.1.4CC: abaron, acathrow, amureini, bazulay, cpelland, dornelas, fsimonce, iheim, jkt, jwest, lpeer, lyarwood, mkalinin, scohen, yeylon
Target Milestone: ---Keywords: Regression, ZStream
Target Release: 3.3.0Flags: amureini: Triaged+
Hardware: x86_64   
OS: Linux   
Whiteboard: storage
Fixed In Version: is3 Doc Type: Bug Fix
Doc Text:
Red Hat Enterprise Virtualization does not support static (unmanaged) iSCSI connections presented to the system by iSCSI HBA cards. To work around this issue, VDSM exposes iSCSI HBA cards as Fiber Channel devices.
Story Points: ---
Clone Of:
: 972863 (view as bug list) Environment:
Last Closed: 2014-01-21 11:08:04 EST Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Storage RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 972863    

Description Marina 2013-05-27 10:46:20 EDT
Cannot attach FC storage domain to RHEV when using QLogic iSCSI HBA offload card.
Used to work for him on 2.2 setup, presenting the storage as FC, but stopped working on 3.1.

From engine.log:
2013-05-23 12:59:56,373 INFO  [org.ovirt.engine.core.vdsbroker.vdsbroker.BrokerCommandBase] (ajp-/ Command org.ovirt.engine.core.vdsbroker.vdsbroker.GetDeviceListVDSCommand return value 
Class Name: org.ovirt.engine.core.vdsbroker.vdsbroker.LUNListReturnForXmlRpc
lunList                       Null
mStatus                       Class Name: org.ovirt.engine.core.vdsbroker.vdsbroker.StatusForXmlRpc
mCode                         600
mMessage                      Error block device action: ()

And then, in supervdsm.log (which fails to start):
MainProcess|Thread-486::ERROR::2013-05-23 12:59:56,328::supervdsmServer::80::SuperVdsm.ServerCallback::(wrapper) Error in readSessionInfo
Traceback (most recent call last):
  File "/usr/share/vdsm/supervdsmServer.py", line 78, in wrapper
    return func(*args, **kwargs)
  File "/usr/share/vdsm/supervdsmServer.py", line 135, in readSessionInfo
    return _readSessionInfo(sessionID)
  File "/usr/share/vdsm/storage/iscsi.py", line 104, in readSessionInfo
    port = int(port)
ValueError: invalid literal for int() with base 10: '
Comment 1 Marina 2013-05-27 10:49:23 EDT
Looking at vdsm code, we see, that it recognizes it as iSCSI connection, but then it fails to get all the session's information from the OS:

In multipath.py we go to iscsi.devIsiSCSI and not to FC else section:
            if iscsi.devIsiSCSI(slave):  
>> here it returns true, see below [1]
                pathInfo["type"] = DEV_ISCSI
                sessionID = iscsi.getiScsiSession(slave)
                if sessionID not in knownSessions:
                    # FIXME: This entire part is for BC. It should be moved to
                    # hsm and not preserved for new APIs. New APIs should keep
                    # numeric types and sane field names.
                    sess = iscsi.getSessionInfo(sessionID)
>> here is the exception thrown, from iscsi.py:
    sessionName = "session%d" % sessionID
    connectionName = "connection%d:0" % sessionID
    iscsi_session = "/sys/class/iscsi_session/%s/" % sessionName
    iscsi_connection = "/sys/class/iscsi_connection/%s/" % connectionName
    if not os.path.isdir(iscsi_session) or not os.path.isdir(iscsi_connection):
        raise OSError(errno.ENOENT, "No such session")

    targetname = os.path.join(iscsi_session, "targetname")
    iface = os.path.join(iscsi_session, "ifacename")
    tpgt = os.path.join(iscsi_session, "tpgt")

    user = os.path.join(iscsi_session, "username")
    passwd = os.path.join(iscsi_session, "password")

    paddr = os.path.join(iscsi_connection, "persistent_address")
    pport = os.path.join(iscsi_connection, "persistent_port")

    res = []
    for fname in (targetname, tpgt, user, passwd, paddr, pport, iface):
            with open(fname, "r") as f:
        except (OSError, IOError):

    iqn, tpgt, username, password, ip, port, iface = res
    port = int(port)  
>> the failure is here, since no port information is collected, see [2] for details
    tpgt = int(tpgt)
[1] in iscsi.py
def devIsiSCSI(dev):
    hostdir = os.path.realpath(os.path.join("/sys/block", dev, "device/../../.."))
    host = os.path.basename(hostdir)
    iscsi_host = os.path.join(hostdir, constants.STRG_ISCSI_HOST, host)
    scsi_host = os.path.join(hostdir, constants.STRG_SCSI_HOST, host)
    proc_name = os.path.join(scsi_host, "proc_name")
    return (os.path.exists(iscsi_host) and os.path.exists(proc_name))

So hostdir & iscsi_host & scsi_host = TRUE # ll /sys/block/<dev>/device/../../..  IE: 

drwxr-xr-x 3 root root    0 May 24 17:44 iscsi_host
drwxr-xr-x 2 root root    0 May 24 17:45 power
drwxr-xr-x 3 root root    0 May 24 17:44 scsi_host
drwxr-xr-x 6 root root    0 May 24 17:44 session1
lrwxrwxrwx 1 root root    0 May 24 17:44 subsystem -> ../../../bus/scsi
-rw-r--r-- 1 root root 4096 May 24 17:44 uevent

# cat /sys/block/sdc/device/../../../scsi_host/host6/proc_name

return TRUE
[2] in iscsy.py:
def getiScsiSession(dev):
    # FIXME: Use the new session object instead of a string
    device = os.path.realpath(os.path.join("/sys/block", dev, "device"))
    sessiondir = os.path.realpath(os.path.join(device, "../.."))
    session = os.path.basename(sessiondir)
    return int(session[len('session'):])

Again, # ll /sys/block/sdc/device/../..

drwxr-xr-x 4 root root    0 May 24 17:44 connection1:0
drwxr-xr-x 3 root root    0 May 24 17:44 iscsi_session
drwxr-xr-x 2 root root    0 May 24 17:52 power
drwxr-xr-x 5 root root    0 May 24 17:44 target6:0:0
-rw-r--r-- 1 root root 4096 May 24 17:44 uevent

And then we are trying to collect session information and update the session fields, but fail, since on customer side there is no such fields as port:
# ll /sys/block/sdc/device/../../iscsi_session/session1/
[root@phrhv05 ~]# ll /sys/block/sda/device/../../iscsi_session/session1/
total 0
-r--r--r--. 1 root root 4096 May 25 07:40 creator
lrwxrwxrwx. 1 root root    0 May 24 16:00 device -> ../../../session1
drwxr-xr-x. 2 root root    0 May 25 07:40 power
-rw-r--r--. 1 root root 4096 May 24 15:59 recovery_tmo
-r--r--r--. 1 root root 4096 May 25 07:40 state
lrwxrwxrwx. 1 root root    0 May 24 15:59 subsystem -> ../../../../../../../../../class/iscsi_session
-r--r--r--. 1 root root 4096 May 24 15:59 targetname
-r--r--r--. 1 root root 4096 May 24 15:59 tpgt
-rw-r--r--. 1 root root 4096 May 24 15:59 uevent
Comment 29 Aharon Canan 2013-08-27 11:27:54 EDT
Following comment #28
marking as verified
Comment 30 Charlie 2013-11-27 19:28:23 EST
This bug is currently attached to errata RHBA-2013:15291. If this change is not to be documented in the text for this errata please either remove it from the errata, set the requires_doc_text flag to 
minus (-), or leave a "Doc Text" value of "--no tech note required" if you do not have permission to alter the flag.

Otherwise to aid in the development of relevant and accurate release documentation, please fill out the "Doc Text" field above with these four (4) pieces of information:

* Cause: What actions or circumstances cause this bug to present.
* Consequence: What happens when the bug presents.
* Fix: What was done to fix the bug.
* Result: What now happens when the actions or circumstances above occur. (NB: this is not the same as 'the bug doesn't present anymore')

Once filled out, please set the "Doc Type" field to the appropriate value for the type of change made and submit your edits to the bug.

For further details on the Cause, Consequence, Fix, Result format please refer to:


Thanks in advance.
Comment 31 errata-xmlrpc 2014-01-21 11:08:04 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.