Skip Navigation Links | |
Exit Print View | |
Oracle Solaris 11.1 Administration: SAN Configuration and Multipathing Oracle Solaris 11.1 Information Library |
1. Solaris I/0 Multipathing Overview
2. Fibre Channel Multipathing Configuration Overview
3. Configuring Solaris I/O Multipathing Features
Configuring Multipathing I/O Features
Enabling and Disabling Multipathing
How to Determine if Multipathing is Enabled or Disabled
Enabling or Disabling Multipathing on a Per-Port Basis
Port Configuration Considerations
How to Configure Multipathing by Port
Configuring Third-Party Storage Devices
Third-Party Device Configuration Considerations
Configuring Third-Party Storage Devices: New Devices
How to Configure Third-Party Devices
Configuring Third-Party Storage Devices: Disabling Devices
Configuring Automatic Failback
How to Configure Automatic Failback
4. Administering Multipathing Devices
5. Configuring Fabric-Connected Devices
6. Configuring Solaris iSCSI Initiators
7. Configuring Virtual Fibre Channel Ports
10. Configuring IPFC SAN Devices
11. Booting the Oracle Solaris OS From Fibre Channel Devices on x86 Based Systems
12. Persistent Binding for Tape Devices
A. Manual Configuration for Fabric-Connected Devices
Note - Before configuring any third-party device, ensure that they are supported. Refer to your third-party user documentation or third-party vendor for information on proper vendor and product IDs, modes, and various settings required for the device to work with multipathing software.
Before you configure third-party devices for multipathing, be aware of the following:
The device must support the REPORT_LUNS SCSI command, and SCSI-3 INQUIRY command VPD Device Identification Page (0x83).
You will need the vendor ID (VID) and product ID (PID) of the device. You can obtain them by using the format command followed by the inquiry option on your system. For more information, see format(1M).
When multipathing is enabled, the multipath access still depends on a device-specific scsi_vhci failover implementation accepting the device. The default is for the scsi_vhci code to automatically call a probe function in each failover implementation, looking for the first probe result that indicates the device is supported.
A probe implementation determines support based on some combination of scsi_inquiry(9S) data. A device with INQUIRY data indicating T10 Target-Port-Group-Support (TPGS) compliance will use the standards-based TPGS failover implementation. For noncompliant devices, a failover implementation's probe will typically determine support based on VID/PID match against a private compiled-in table.
To override the probe process, the scsi_vhci.conf file supports a scsi-vhci-failover-override property. The value of scsi-vhci-failover-override can be used to establish support for a device not currently accepted by probe, override probe support, or disable multipath support for a device.
Multipathing can be configured on third-party symmetric storage devices. A symmetric storage device is one in which all paths to the storage device are active and I/O commands can be issued through any path.
Perform the following steps to configure third-party devices if your system already has multipathing enabled. If your system has multipathing disabled, you can configure third-party devices while enabling multipathing as described earlier in this chapter.
The vendor ID and product ID are the vendor and product identification strings that the device returns in SCSI INQUIRY data. The vendor ID must be eight characters long. You must specify all eight characters even if the trailing characters are spaces.
The product ID can be up to 16 characters long.
scsi-vhci-failover-override = "VendorID1ProductID1", "f_sym", "VendorID2ProductID2", "f_sym", ... "VendorIDnProductIDn", "f_sym";
Note that the entries are separated by the ’,’ character (a comma) and the last vendor/product entry is terminated by the ’;’ character (a semicolon).
For example, to add a device from a vendor,“ACME,” with a product ID of “MSU” and a device from vendor “XYZ” with a product ID of “ABC”, you would add the following lines to the /etc/driver/drv/scsi_vhci.conf file:
scsi-vhci-failover-override = "ACME MSU", "f_sym", "XYZ ABC", "f_sym";
# stmsboot -u
You are prompted to reboot. During the reboot, the /etc/vfstab file and the dump configuration are updated to reflect the device name changes.
Multipathing can be disabled for all devices of a certain vendor ID/product ID combination. This exclusion is specified in the scsi_vhci.conf file.
The vendor ID and product ID are the vendor and product identification strings that the device returns in SCSI INQUIRY data. The vendor ID must be eight characters long. You must specify all eight characters even if the trailing characters are spaces. The product ID can be up to 16 characters long.
scsi-vhci-failover-override = "VendorID1ProductID1", "NONE", "VendorID2ProductID2", "NONE", ... "VendorIDnProductIDn", "NONE";
The entries in the preceding example are separated by the ’,’ character (a comma) and the last vendor/product entry is terminated by the ’;’ character (a semicolon). For example, to add a device from vendor “ACME” with a product ID of “MSU,” and a vendor device from vendor “XYZ” with product ID “ABC,” you would add the following lines to the file /etc/driver/drv/scsi_vhci.conf:
scsi-vhci-failover-override = "ACME MSU", "NONE", "XYZ ABC", "NONE";
# stmsboot -u
You are prompted to reboot. During the reboot, the /etc/vfstab file and the dump configuration are updated to reflect the device name changes.
You can display the mapping between non-multipathed and multipathed device names after changes are made to the multipath configuration by invoking the stmsboot command with the -e, -d, or -u option. Both non-multipathed and the multipathed device names must exist in order to show the mapping.
Display the mapping of devices on all controllers. For example:
# stmsboot -L non-STMS device name STMS device name ---------------------------------------------------------------- /dev/rdsk/c2t8d0 /dev/rdsk/c10t500000E01046DEE0d0 /dev/rdsk/c2t0d0 /dev/rdsk/c10t500000E01046B070d0 /dev/rdsk/c2t3d0 /dev/rdsk/c10t20000020372A40AFd0 /dev/rdsk/c2t12d0 /dev/rdsk/c10t500000E01046DEF0d0 /dev/rdsk/c2t11d0 /dev/rdsk/c10t500000E01046E390d0 /dev/rdsk/c3t8d0 /dev/rdsk/c10t500000E01046DEE0d0 /dev/rdsk/c3t0d0 /dev/rdsk/c10t500000E01046B070d0 /dev/rdsk/c3t3d0 /dev/rdsk/c10t20000020372A40AFd0 /dev/rdsk/c3t12d0 /dev/rdsk/c10t500000E01046DEF0d0 /dev/rdsk/c3t11d0 /dev/rdsk/c10t500000E01046E390d0
The -l option displays the mapping of devices on only the specified controller. The following example displays the mapping of controller 3.
# stmsboot -l3 non-STMS device name STMS device name ---------------------------------------------------------------- /dev/rdsk/c3t8d0 /dev/rdsk/c10t500000E01046DEE0d0 /dev/rdsk/c3t0d0 /dev/rdsk/c10t500000E01046B070d0 /dev/rdsk/c3t3d0 /dev/rdsk/c10t20000020372A40AFd0 /dev/rdsk/c3t12d0 /dev/rdsk/c10t500000E01046DEF0d0 /dev/rdsk/c3t11d0 /dev/rdsk/c10t500000E01046E390d0