Bug 215469

Summary:	blacklisting of local scsi devices needs to be more finegrained
Product:	Red Hat Enterprise Linux 4	Reporter:	NetApp filed bugzillas <xdl-redhat-bugzilla>
Component:	device-mapper-multipath	Assignee:	Ben Marzinski <bmarzins>
Status:	CLOSED ERRATA	QA Contact:	Corey Marthaler <cmarthal>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.4	CC:	agk, bmarzins, christophe.varoqui, dwysocha, egoggin, junichi.nomura, kueda, lmb, mbroz, prockai, tranlan
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	RHEA-2007-0256	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-05-01 17:45:40 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:

Description NetApp filed bugzillas 2006-11-14 07:38:21 UTC

Description of problem:
Currently there is no entry for blacklisting of scsi devices in the default 
templates of multipath package.
This makes the user assume to use the following setting convention (which is 
in the template for ide drives) for scsi devices also.
^hd[a-z]

The problem is that the same setting for a scsi device can be problematic:
^sd[a] leads both to sda, sdaa, sdab ....
Hence it blacklists other devices where we only wanted to blacklist the single 
local sda scsi device.

We propose the inclusion of the following settings in the default templates 
for multipath.conf to assist users.
sda$
which specifically means to blacklist only and only the sda device.

How reproducible:
Always

Steps to Reproduce:
1. Add as many devices till sdz is reached. the next device would be sdaa
2. Try blacklisting the devices, devnode "sda"
3. It blacklists all devices starting with sda.
  
Actual results:
It is blacklisting all devices all devices starting with sda

Expected results:
Should blacklist only device sda.

Additional info:

Comment 1 Ben Marzinski 2006-12-01 21:06:59 UTC

People shouldn't blacklist individual devices this way. Using the devnode method
of blacklisting is fine for knocking out whole types of devices, but since there
is no guarantee that the device registered as /dev/sda on one boot will be
registered as /dev/sda on the next, blacklisting individual devices by devnode
is risky and not recommended. People should blacklist the devices by wwid
instead. I realize that people don't do this often, and unless new devices are
added, it's
really almost never a problem to use the devnode method, but it's still not ideal.

I suppose that I should add a comment saying something like this to the
/etc/multipath.conf.

Comment 2 NetApp filed bugzillas 2006-12-03 20:36:54 UTC

Thats right. It does make a lot of sense blacklisting devices using the WWID
instead of device names in the multipath.conf file. I am aware of the 'scsi_id'
command which can be used to retrieve the WWID of a SCSI device as in:
'scsi_id -p 0x83 -g -s /block/<SCSI device>

But this command does not always work for local disks (which need blacklisting).
On one of my hosts, the above command gave a blank output. On another one, it
gave the following output:

[root@lnx200-127 ~]# scsi_id -p 0x83 -g -s /block/sda
0:0:0:0: sg_io failed status 0x8 0x0 0x0 0x2         
0:0:0:0: sense key 0x5 ASC 0x24 ASCQ 0x0             
0:0:0:0: Unable to get INQUIRY vpd 1 page 0x83.

So is there any simple foolproof method to obtain the WWID of a SCSI device?

Comment 3 NetApp filed bugzillas 2006-12-04 19:16:58 UTC

Apparently "scsi_id -g -u -s /block/<SCSI device>" seems to work fine for all
cases including the ones described above. The unique device id generated by this
command could be used for blacklisting SCSI disks in the multipath.conf file.

Comment 10 Red Hat Bugzilla 2007-05-01 17:45:40 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 the 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/RHEA-2007-0256.html