Bug 619173 - RFE: add support for StorageTek 6180
Summary: RFE: add support for StorageTek 6180
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: device-mapper-multipath
Version: 6.4
Hardware: All
OS: Linux
medium
medium
Target Milestone: beta
: 6.4
Assignee: Ben Marzinski
QA Contact: Gris Ge
URL:
Whiteboard:
Depends On:
Blocks: 846704
TreeView+ depends on / blocked
 
Reported: 2010-07-28 18:54 UTC by Anthony Green
Modified: 2013-02-21 10:49 UTC (History)
22 users (show)

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):
Clone Of:
Environment:
Last Closed: 2013-02-21 10:49:24 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0458 normal SHIPPED_LIVE device-mapper-multipath bug fix and enhancement update 2013-02-20 21:07:30 UTC

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


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