Bug 619173

Summary:	RFE: add support for StorageTek 6180
Product:	Red Hat Enterprise Linux 6	Reporter:	Anthony Green <green>
Component:	device-mapper-multipath	Assignee:	Ben Marzinski <bmarzins>
Status:	CLOSED ERRATA	QA Contact:	Gris Ge <fge>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.4	CC:	agk, bmarzins, bmr, christophe.varoqui, coughlan, cww, czhang, dwysocha, dyasny, fge, heinzm, james.brown, joerg.reuter, junichi.nomura, jwest, kueda, lmb, msnitzer, prajnoha, prockai, stanislav.polasek, zkabelac
Target Milestone:	beta	Keywords:	FutureFeature
Target Release:	6.4
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	device-mapper-multipath-0.4.9-59.el6	Doc Type:	Enhancement
Doc Text:	Feature: Added built-in configuration for SUN StorageTek 6180. Reason: Result (if any):	Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-02-21 10:49:24 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:	846704

Description Anthony Green 2010-07-28 18:54:27 UTC

Description of problem:
Sun/Oracle StorageTek 6180 is supported for use with RHEL by Oracle if you use their LSI's MPP RDAC driver for multipath support.  This is inconvenient because you have to rebuild/install this driver whenever you upgrade the kernel.  I know that people are using the 6140 with dm-multipath, and the 6180 is (I believe) just a larger/faster 6140, however, it doesn't appear to be certified by us for use with dm-multipath so users are force to use MPP RDAC as a fully supported solution.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 2 Ben Marzinski 2010-07-29 22:32:39 UTC

multipath does indeed autoconfigure for the 6140. Do we have access to a 6180 array, to test the configuration on.  Also, I have no idea what the vendor/product values are, and without knowing these, we can't write a multipath configuration for it

Comment 4 Ben Marzinski 2010-07-30 17:53:54 UTC

vendor comes from:
/sys/block/<device_from_this_storage>/device/vendor

product comes from:
/sys/block/<device_from_this_storage>/device/model

The 6140 configuration section looks like this.

devices {
       device {
               vendor                  "SUN"
               product                 "CSM200_R"
               getuid_callout          "/sbin/scsi_id -g -u -s /block/%n"
               prio_callout            "/sbin/mpath_prio_rdac /dev/%n" 
               features                "0"
               hardware_handler        "1 rdac"
               path_grouping_policy    group_by_prio
               failback                immediate
               rr_weight               uniform
               no_path_retry           queue
               rr_min_io               1000
               path_checker            rdac
       }
}

The customer needs to make sure the "vendor" and "product" fields match their device.

We usually only add default configurations based on in-house testing or that come from trusted sources.  I'm fine with working with the customer to get this working, but QA needs to make the final call if we can consider this validated without any in-house testing, and without guidance from the hardware vendor.

Comment 5 J. Reuter 2010-11-02 10:56:49 UTC

We are using several StorageTek 6180 arrays, which do not work correctly with the default configuration. I took the entry for the 6140 from the multipath.conf.defaults, copied it to the multipath.conf, and changed the "product" field to "SUN_6180":

devices {
       device {
               vendor                  "SUN"
               product                 "SUN_6180"
               getuid_callout          "/sbin/scsi_id -g -u -s /block/%n"
               prio_callout            "/sbin/mpath_prio_rdac /dev/%n" 
               features                "0"
               hardware_handler        "1 rdac"
               path_grouping_policy    group_by_prio
               failback                immediate
               rr_weight               uniform
               no_path_retry           queue
               rr_min_io               1000
               path_checker            rdac
       }
}

Using that, the system is running fine now, and failover and failback are working as they should, even under load. Thanks for the suggestion!

Comment 12 Ben Marzinski 2012-10-10 16:00:57 UTC

Default configuration added.

Comment 15 Gris Ge 2012-11-26 06:18:40 UTC

Buildin config for 6180 found in device-mapper-multipath-0.4.9-62.el6.x86_64
===
device {
	vendor "SUN"
	product "SUN_6180"
	path_grouping_policy group_by_prio
	getuid_callout "/lib/udev/scsi_id --whitelisted --device=/dev/%n"
	path_selector "round-robin 0"
	path_checker rdac
	features "0"
	hardware_handler "1 rdac"
	prio rdac
	failback immediate
	rr_weight uniform
	no_path_retry queue
	rr_min_io 1000
	rr_min_io_rq 1
}
===

No hardware to play on for failover and othe test.

SanityOnly.

Comment 17 errata-xmlrpc 2013-02-21 10:49:24 UTC

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.

http://rhn.redhat.com/errata/RHBA-2013-0458.html