SUN72G SAS drives refuse to be mpxio'ed
"James Noyes (SunManagers)" <[email protected]> Tue, 12 Nov 2013 10:42:19 -0700
| Newsgroups | gmane.os.solaris.managers |
|---|---|
| Message-ID | <[email protected]> |
Fellow Managers: I've used mpxio with great success for many years, with both FC and SAS storage. I've never had a problem making it do what I need it to do, until now. I typically use mpxio globally, even when the storage is single-pathed, so that the drive identifier is tied to the drive, not to its physical location. Now all of a sudden, I've run into a batch of drives that - for whatever reason - simply REFUSE to let the scsi_vhci module bind to them. System is a T5220 running Solaris 10 1/13, with latest Recommended patches. I have a mixture of 72G, 146G, and 300G SAS 2.5" drives available to use. All of the drives are Sun-labeled and Sun-firmwared drives. Some are Seagate, some Fujitsu, a couple are Hitachi OEM - but all genuine Sun parts. The 146G and 300G drives all do what's expected. With mpxio enabled, they all appear as their respective device using their WWN as the target (e.g., /dev/dsk/c5t5000500fd38b9278d0 and so on). Under "cfgadm -al", the devices show as a "disk-path" type: (c1::2,0 disk-path connected configured unknown). "mpathadm list lu" shows the devices, even though the total/operational path counts are both 1. So far, so good. But the 72G drives are a different story. No matter WHAT I do, these drives always show up as the typical cXtXdX devices. "cfgadm -al" shows them differently as well - as "disk" type: (c1::dsk/c1t3d0 disk connected configured unknown). Even if I explicitly add the sometimes-necessary "device-type-scsi-options" and "symmetric-options" parameters to scsi_vhci.conf to force multipathing, the system seems to simply ignore it. "mpathadm list lu" shows no trace of them. What is it about these drives? I'm pretty sure I haven't missed anything in the mpxio configuration, since all the other drives work as expected. Is it something in their firmware? Something about them physically? Why won't the scsi_vhci driver attach/take control of them? I'd like to use them, but I'd like to have consistent behavior with the rest of the drives if I do. I welcome any suggestions/comments/questions. -- Cheers, James Noyes ([email protected])