Bug 512065

Summary: [NetApp 4.9 bug] "multipath -v3" displays tgt_node_name as blank for iscsi devices
Product: Red Hat Enterprise Linux 4 Reporter: Tanvi <tanvi>
Component: device-mapper-multipathAssignee: Ben Marzinski <bmarzins>
Status: CLOSED ERRATA QA Contact: Cluster QE <mspqa-list>
Severity: high Docs Contact:
Priority: high    
Version: 4.8CC: agk, andriusb, bdonahue, bmarzins, christophe.varoqui, coughlan, dwysocha, egoggin, gowrav.mahadevaiah, heinzm, iannis, junichi.nomura, kueda, lmb, mbroz, prockai, tranlan, xdl-redhat-bugzilla
Target Milestone: betaKeywords: OtherQA
Target Release: 4.9   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: device-mapper-multipath-0.4.5-40.el4 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 650795 650797 (view as bug list) Environment:
Last Closed: 2011-02-16 14:24:51 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: 626414, 650795, 650797    

Description Tanvi 2009-07-16 06:32:36 UTC
Description of problem:
On a RHEL4.8 host, it has been seen that "multipath -v3" displays tgt_node_name as blank.

===== path info sdaa (mask 0x1f) =====
bus = 1
dev_t = 65:160
size = 41943040
vendor = NETAPP
product = LUN
rev = 7310
h:b:t:l = 48:0:0:5
tgt_node_name =
serial = HnSwO4QIhOTq
path checker = readsector0 (controler setting)
state = 2
getprio = /sbin/mpath_prio_netapp /dev/%n (controler setting)
prio = 2
getuid = /sbin/scsi_id -g -u -s /block/%n (controler setting)
uid = 360a98000486e53774f345149684f5471 (callout)
path sdab not found in pathvec

The reason for this is that multipath looks in sysfs at a hardcoded FC path. Following is the code snippet from libmultipath/discovery.c file.
  */
        if(safe_sprintf(attr_path,
                        "%s/class/fc_transport/target%i:%i:%i/node_name",
                        sysfs_path,
                        curpath->sg_id.host_no,
                        curpath->sg_id.channel,
                        curpath->sg_id.scsi_id)) {
                condlog(0, "attr_path too small");
                return 1;
        }

Here, path is being assigned as %s/class/fc_transport/target%i:%i:%i/node_name. For an iscsi device, we need to look at %s/class/iscsi_transport/target%i:%i:%i/target_name.

Version-Release number of selected component (if applicable):
device-mapper-multipath-0.4.5-35.el4

How reproducible:
Always

Steps to Reproduce:
1.Map some iscsi LUNs to the host
2.Run multipath -v3
  
Actual results:
No value is displayed for tgt_node_name

Expected results:
multipath -v3 should display correct target name.

Comment 2 Ben Marzinski 2010-05-25 23:23:44 UTC
multipath will now check for the iscsi target name if the fc check fails.

Comment 4 gowrav 2011-02-15 13:14:50 UTC
Verified the fix with "device-mapper-multipath-0.4.5-41.el4" which is available with RHEL 4.9 OS. The iscsi target name is getting displayed correctly now.

[root@IBMblade-200-202 ~]# multipath -v3 | grep tgt
tgt_node_name = iqn.1992-08.com.netapp:sn.101180506
tgt_node_name = iqn.1992-08.com.netapp:sn.101180506
tgt_node_name = iqn.1992-08.com.netapp:sn.101180506
tgt_node_name = iqn.1992-08.com.netapp:sn.101180506
tgt_node_name = iqn.1992-08.com.netapp:sn.101180506
tgt_node_name = iqn.1992-08.com.netapp:sn.101180506
tgt_node_name = iqn.1992-08.com.netapp:sn.101180506
tgt_node_name = iqn.1992-08.com.netapp:sn.101180506
tgt_node_name = iqn.1992-08.com.netapp:sn.101180456
tgt_node_name = iqn.1992-08.com.netapp:sn.101180456
tgt_node_name = iqn.1992-08.com.netapp:sn.101180456
tgt_node_name = iqn.1992-08.com.netapp:sn.101180456
tgt_node_name = iqn.1992-08.com.netapp:sn.101180456
tgt_node_name = iqn.1992-08.com.netapp:sn.101180456

This bug can be now be resolved.

Comment 5 errata-xmlrpc 2011-02-16 14:24:51 UTC
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-0243.html