SUMMARY: problems setting up mpxio

From: Tom Lieuallen <>
Date: Wed Nov 26 2008 - 14:31:18 EST
I don't have the fix, but I do see now why it isn't working.

 From the Solaris SAN Configuration and Multipathing Guide, it lists 
these requirements for 3rd party storage devices:

The device must support the REPORT_LUNS SCSI command, and SCSI-3 INQUIRY 
command VPD Device Identification Page (0x83).

It appears that these disks do not support the page 83 Device ID.

This is what a working disk reports:

scu> show inquiry pages supported

Vital Product Data Pages Supported by Device /dev/rdsk/c0t25d0s2 

             Supported Vital Product Data Page (Code = 0x00)
                       Unit Serial Number Page (Code = 0x80)
        Implemented Operating Definitions Page (Code = 0x81)
                    Device Identification Page (Code = 0x83)
                          Vendor Specific Page (Code = 0xc0)
                          Vendor Specific Page (Code = 0xc1)
                          Vendor Specific Page (Code = 0xc2)
                          Vendor Specific Page (Code = 0xc3)
                          Vendor Specific Page (Code = 0xd1)
                          Vendor Specific Page (Code = 0xd2)

And my FUJITSU disks that are not working with mpxio:

scu> show inquiry pages supported

Vital Product Data Pages Supported by Device /dev/rdsk/c0t42d0s2 

             Supported Vital Product Data Page (Code = 0x00)
                       Unit Serial Number Page (Code = 0x80)
                          Vendor Specific Page (Code = 0xc0)

That manual talks about how this page 83 device id is used by the 
scsi_vhci probe.  It also talks about the ability to override that 
probe, but gives no details.  I can't seem to get anywhere with it on 
google either.

Unfortunately, I don't see any firmware updates for that disk.  So, 
unless someone has insight, I'm going to consider this a lost cause. :-(

BTW, note the 'scu' prompt above.  I found an incredible program named 
scu.  Scsi command utility.  It gives you access to some low level scsi 
commands and information.


Tom Lieuallen
Oregon State University


 > I apologize.  What makes me think that the mpxio setup is not complete
 > or not working correctly is that in format, I still see the two
 > separate paths to the disk, not the new pseudo path with the very,
 > very, very long device names.  I still see /dev/rdsk/c0t43d0s2 and
 > c1t43d0s2 rather than the device based on the WWN.

Tom Lieuallen wrote:
> My recipe for setting up mpxio has been the following:
> * stmsboot -e
> * if 3rd party hardware, add inquiry and product info to 
> /kernel/drv/scsi_vhci.conf
> * stmsboot -u
> This worked for me a few days ago with the following equipment:
> Sun v240, Solaris 10 U5 (tried U6), 2x qlogic qla2340 hba's, an HP 
> DS2305(?) FC JBOD with 15x HP 36GB disks.
> However, I tried it again on the same machine, but with an nstor/xyratex 
> 4900 JBOD with 12x FUJITSU 300GB disks.  I'm having problems getting the 
> multipathing to work.  I'm guessing it has to do with the entries in 
> scsi_vhci.conf, but they look right, unless I need to divert from the 
> defaults.
> ==========
> device-type-scsi-options-list =
> "FUJITSU MAT3300FC", "symmetric-option";
> symmetric-option = 0x1000000;
> ==========
> luxadm probe knows that the devices have multiple paths.  And the 
> display shows things fine to me as well.
> luxadm probe
> ...
> ...
>    Node WWN:500000e0110b5bc0  Device Type:Disk device
>      Logical Path:/dev/rdsk/c0t43d0s2
>      Logical Path:/dev/rdsk/c1t43d0s2
> luxadm display /dev/rdsk/c1t43d0s2
> DEVICE PROPERTIES for disk: /dev/rdsk/c1t43d0s2
>    Status(Port A):       O.K.
>    Status(Port B):       O.K.
>    Vendor:               FUJITSU
>    Product ID:           MAT3300FC
>    WWN(Node):            500000e0110b5bc0
>    WWN(Port A):          500000e0110b5bc1
>    WWN(Port B):          500000e0110b5bc2
>    Revision:             01A3
>    Serial Num:           AG00P5400193
>    Unformatted capacity: 286102.281 MBytes
>    Write Cache:          Enabled
>    Read Cache:           Enabled
>      Minimum prefetch:   0x0
>      Maximum prefetch:   0x0
>    Device Type:          Disk device
>    Path(s):
>    /dev/rdsk/c0t43d0s2
> /devices/pci@1e,600000/fibre-channel@2/fp@0,0/ssd@w500000e0110b5bc2,0:c,raw
>    /dev/rdsk/c1t43d0s2
> /devices/pci@1e,600000/fibre-channel@3/fp@0,0/ssd@w500000e0110b5bc1,0:c,raw
> I ran 'stmsboot -e' again. It does show my FC hba's and says that STMS 
> is already enabled and therefore it does nothing.
> The man page for scsi_vhci mentions device-type-scsi-options-list as 
> well as scsi-vhci-failover-override.  I've always used the 
> device-type-scsi-options-list.  Although I don't know any other value 
> than the symetric-option.  Furthermore, the scsi-vhci-failure-override 
> example uses 'f_sym' and 'NONE' as sample values.  I've seen several 
> other sample values on the internet.  No idea what they're for.  Might 
> these options/values be the answer?  Any other way of debugging this?
> thank you
> Tom Lieuallen
> Oregon State University
> _______________________________________________
> sunmanagers mailing list
sunmanagers mailing list
Received on Wed Nov 26 14:31:46 2008

This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:44:12 EST