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 (ST336752FC): 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 (MAT3300FC): 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. http://home.comcast.net/~SCSIguy/SCSI_FAQ/RMiller_Tools/scu.html Thanks 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@sunmanagers.org > http://www.sunmanagers.org/mailman/listinfo/sunmanagers _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived 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