Version 1 Release 2.1 (8th Edition, June 2001)
| Note: |
|---|
|
Before using this information and the product it supports, read the information in Notices. |
Eight Edition (June 2001)
This edition applies to Version 1 Release 2.1 of the IBM Subsystem Device Driver and to all subsequent releases and modifications until otherwise indicated in new editions.
This edition also includes information that specifically applies to:
Order publications through your IBM representative or the IBM branch office serving your locality.
IBM welcomes your comments; send them to the following address:
International Business Machines
You can also send your comments about this book electronically to:
© Copyright International Business Machines Corporation 1999, 2001. All rights reserved.
U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Summary of changes for the IBM Subsystem Device Driver Installation and User's Guide
Chapter 1. Introducing the IBM Subsystem Device Driver
Chapter 2. Installing and configuring the Subsystem Device Driver on an AIX host
Chapter 3. Using the IBM Subsystem Device Driver on an AIX host system
Chapter 4. Installing and configuring IBM Subsystem Device Driver on a Windows NT host
Chapter 5. Installing and configuring the IBM Subsystem Device Driver on a Windows 2000 host
Chapter 6. Installing and configuring the IBM Subsystem Device Driver on an HP host
Chapter 7. Installing and configuring IBM Subsystem Device Driver on a Sun host
Chapter 8. Using the datapath commands
This document provides information for installing and configuring the IBM Subsystem Device Driver on IBM(R) AIX(R), HP, Sun, Microsoft(R) Windows NT(R), and Microsoft(R) Windows 2000 hosts.
This publication is for storage administrators, system programmers, and performance and capacity analysts.
The following related publications are also available:
This book describes how to use the IBM Subsystem Device Driver on open-systems hosts to enhance performance and availability on the ESS. The Subsystem Device Driver creates redundant paths for shared logical unit numbers. The Subsystem Device Driver permits applications to run without interruption when path errors occur. It balances the workload across paths, and it transparently integrates with applications.
This publication is not available in hard copy. However, it is available on the CD that is delivered with your ESS. You can also view and copy this publication from the Web site:
www.ibm.com/storage/support/techsup/swtechsup.nsf/support/sddupdates
This book, from the IBM International Technical Support Organization, introduces the IBM Enterprise Storage Server (ESS) and provides an understanding of its benefits. It also describes in detail the architecture, hardware and functions of the ESS.
This book, from the IBM International Technical Support Organization, can help you install, tailor, and configure the IBM Enterprise Storage Server (ESS) in your environment.
This guide introduces the product and lists the features you can order. It also provides guidelines on planning for the installation and configuration of the ESS.
The summary of changes informs you of changes to this book. Revision bars (|) in the left margin of the book indicate changes from the previous edition.
This book contains information previously presented in Subsystem Device Driver Installation and User's Guide Version 1 Release 2.1 March 2001. The following sections summarize the changes that have been made to the book since that edition.
This edition includes the following new information:
What's new in Chapter 2, Installing and configuring the Subsystem Device Driver on an AIX host:
What's new in Chapter 3, Using the IBM Subsystem Device Driver on an AIX host system:
What's new in Chapter 4, Installing and configuring IBM Subsystem Device Driver on a Windows NT host:
What's new in Chapter 5, Installing and configuring the IBM Subsystem Device Driver on a Windows 2000 host:
What's new in Chapter 6, Installing and configuring the IBM Subsystem Device Driver on an HP host:
What's new in Chapter 7, Installing and configuring IBM Subsystem Device Driver on a Sun host:
This edition includes the following modified information:
What's modified in Chapter 2, Installing and configuring the Subsystem Device Driver on an AIX host:
What's modified in Chapter 3, Using the IBM Subsystem Device Driver on an AIX host system:
What's modified in Chapter 5, Installing and configuring the IBM Subsystem Device Driver on a Windows 2000 host:
What's modified in Chapter 6, Installing and configuring the IBM Subsystem Device Driver on an HP host:
The IBM Subsystem Device Driver resides in the host server with the native disk device driver for the IBM Enterprise Storage Server (ESS). It uses redundant connections between the host server and disk storage in an ESS to provide enhanced performance and data availability.
Figure 1 is an example of the type of configuration that IBM Subsystem Device Driver supports. These connections comprise many different components through which data flows during input and output processes. Redundancy and the ability to switch between these components provides many different paths for the data to travel. In the event of failure in one input-output path, it automatically switches to another input-output path. This automatic switching in the event of failure is called failover.
Figure 1. Multipath connections between a host server and ESS logical unit numbers (LUNs)
The Subsystem Device Driver provides the following functions:
In most cases, host servers are configured with multiple host adapters with SCSI or fibre-channel connections to an ESS that, in turn, provides internal component redundancy. With dual clusters and multiple host interface adapters, the ESS provides more flexibility in the number of input-output (I/O) paths that are available.
When there is a failure, the Subsystem Device Driver reroutes I/O operations from the failed path to the remaining paths. This function eliminates the following connections as single points of failure: a bus adapter on the host server, an external SCSI cable, a fiber-connection cable, or a host interface adapter on the ESS.
In addition, multipath load balancing of data flow prevents a single path from becoming overloaded with I/O operations.
Concurrent download of licensed internal code is the capability to download and install licensed internal code on an ESS while applications continue to run. During the time when new licensed internal code is being installed in an ESS, the upper-interface adapters inside the ESS may not respond to host I/O requests for approximately 30 seconds. The Subsystem Device Drivers makes this transparent to the host through its path selection and retry algorithms.
The path algorithms basically work the same for all the platforms that the Subsystem Device Driver runs on. There are two modes of operation:
Table 1. Number of successful I/O operations performed before putting path into Open state
| Operating System | Number of I/O operations |
|---|---|
| AIX | 50 000 |
| Windows NT | 50 000 |
| Windows 2000 | 50 000 |
| HP | 200 000 |
| Solaris | 200 000 |
If the first I/O operation fails after the path is put back into the Open state, the Subsystem Device Driver puts the path into the Dead state immediately and permanently. You must manually bring the path online by using the datapath command.
This chapter provides instructions for installing and setting up the IBM Subsystem Device Driver on an AIX host system attached to an ESS. The IBM Subsystem Device Driver/Data Path Optimizer on an ESS--Installation Procedures/Potential Gotchas publication is a very helpful source of information. This is especially true if you have SP systems. This publication can be found at the following Web site:
Notes:
The following section briefly describes the Subsystem Device Driver failover system and the device driver. A table describing the support for 32-bit and 64-bit applications is included.
The Subsystem Device Driver failover system is designed to provide recovery upon failure of a data path. If a data path fails, the failover system selects an alternate data path and minimizes any disruptions in operation. This failover process consists of the following actions:
The Subsystem Device Driver dynamically selects an alternate I/O data path when a software or hardware problem is detected.
The Subsystem Device Driver resides above the AIX disk driver in the protocol stack. Each Subsystem Device Driver device represents a unique physical device on the storage subsystem. There can be up to 32 hdisk devices that represent up to 32 different paths to the same physical device. See Figure 2.
Figure 2. Where the Subsystem Device Driver fits in the protocol stack
Subsystem Device Driver devices behave almost like hdisk devices. Most operation on an hdisk device can be performed on the Subsystem Device Driver device, including commands such as open, close, dd, or fsck.
The Subsystem Device Driver acts as a pseudo device driver. I/O operations sent to the Subsystem Device Driver are passed to the AIX disk driver after path selection. When an active path experiences a failure (such as a cable or controller failure), the Subsystem Device Driver dynamically switches to another path. The device driver dynamically balances the load, based on the workload of the adapter.
The Subsystem Device Driver also supports one SCSI adapter on the host
system. With SCSI single-path access, concurrent download of licensed
internal code is supported. However, the load-balancing and failover
features are not available.
|Support for 32-bit and 64-bit applications on AIX 4.3.3
|Table 2 summarizes the Subsystem Device Driver support for
|32-bit and 64-bit applications on AIX 4.3.3
|Table 2. Support for 32-bit and 64-bit applications
|
Application mode
Subsystem Device Driver interface
AIX kernel/Subsystem Device Driver
Support
32-bit =======>
raw device ===>
32-bit
Yes
32-bit =======>
LVM ========>
32-bit
Yes
64-bit =======>
raw device ===>
32-bit
No
64-bit =======>
LVM ========>
32-bit
Yes (if all I/O uses LVM)
32-bit =======>
raw device ===>
64-bit
Not currently available
32-bit =======>
LVM ========>
64-bit
Not currently available
64-bit =======>
raw device ===>
64-bit
Not currently available
64-bit =======>
LVM ========>
64-bit
Not currently available
The following hardware and software components must be installed to ensure that the Subsystem Device Driver installs and operates successfully.
To successfully install the Subsystem Device Driver, you must have AIX
4.2.1, 4.3.2, or 4.3.3 installed on
your host system along with the fixes shown in Table 3.
Table 3. AIX PTF required fixes
| AIX level | PTF number | Component name | Component level |
|---|---|---|---|
| 4.2.1 | IX62304 |
|
|
|
| U451711 | perfagent.tools | 2.2.1.4 |
|
| U453402 | bos.rte.libc | 4.2.1.9 |
|
| U453481 | bos.adt.prof | 4.2.1.11 |
|
| U458416 | bos.mp | 4.2.1.15 |
|
| U458478 | bos.rte.tty | 4.2.1.14 |
|
| U458496 | bos.up | 4.2.1.15 |
|
| U458505 | bos.net.tcp.client | 4.2.1.19 |
|
| U462492 | bos.rte.lvm | 4.2.1.16 |
| 4.3.2 | U461953 | bos.rte.lvm | 4.3.2.4 |
You must check for the latest information on APARs, maintenance level fixes and microcode updates at the following downloadable Web site:
To successfully install the Subsystem Device Driver, ensure that your ESS meets the following requirements:
To use the Subsystem Device Driver SCSI support, ensure your host system meets the following requirements:
For information about the SCSI adapters that can attach to your AIX host system, go to the following Web site:
To use the Subsystem Device Driver fibre support, ensure your host system meets the following requirements:
The Emulex LP70000E adapter should be attached to its own PCI bus and the adapter should not be shared with other PCI adapters.
Notes:
For information about the fibre-channel adapters that can be used on your AIX host system go to the following Web site:
The following environments are not supported by the Subsystem Device Driver:
Before you install the Subsystem Device Driver, configure your ESS for single-port or multiple-port access for each LUN. The Subsystem Device Driver requires a minimum of two independent paths that share the same logical unit to use the load-balancing and failover features.
For more information about configuring your IBM Enterprise Storage Server, see the IBM Enterprise Storage Server Introduction and Planning Guide..
AIX fibre-channel device drivers are developed by IBM for the Emulex LP7000E adapter.
This section contains the procedures for installing fibre-channel device drivers and configuring fibre-channel devices. These procedures include:
This section also contains procedures for:
|Requirement: For fibre-channel support, the AIX |host system must be an IBM RS/6000 system with AIX Version |4.3.3. The AIX host system should have the fibre-channel |device drivers installed along with APARS IY10201, IY10994, IY11245, IY13736, |IY17902, and IY18070.
Perform the following steps to install the AIX fibre-channel device drivers:
The newly installed devices must be configured before they can be used. There are two ways to configure these devices. You can:
After the system restarts, use the lsdev -Cc disk command to check the ESS fibre-channel protocol (FCP) disk configuration. If the FCP devices are configured correctly, they should be in the Available state. If the FCP devices are configurated correctly, go to Determining the Emulex adapter firmware level (sf320A9) to determine if the proper firmware level is installed.You are required to install new adapter firmware only if the current adapter firmware is not at the sf320A9 level. Perform the following steps to download the Emulex adapter firmware:
+--------------------------------------------------------------------------------+ |(ZB).............S2F3.20A9 | +--------------------------------------------------------------------------------+
To determine the firmware level, ignore the second character in the ZB field. In the example, the firmware level is sf320A9.
Upgrading the firmware level consists of downloading the firmware (microcode) from your AIX host system to the adapter. Before this can be done, however, the fibre-channel attached devices must be configured. After the devices are configured, you are ready to download the firmware from the AIX host system to the FCP adapter. Perform the following steps to download the firmware:
To remove all fibre-channel attached devices, you must issue the rmdev -dl fcsN -R command for each installed FCP adapter, where N is the FCP adapter number. For example, if you have two installed FCP adapters (adapter 0 and adapter 1), you must issue both the commands: rmdev -dl fcs0 -R and the rmdev -dl fcs1 -R
There are two methods for uninstalling all of your fibre-channel device drivers. You can:
Perform the following steps to use the smitty deinstall command:
Perform the following steps to use the installp command from the AIX command line:
You must have root access and AIX system administrator knowledge to install the Subsystem Device Driver.
To install the Subsystem Device Driver, use the installation package that
is appropriate for your environment. Table 4 lists and describes the installation package file names
(filesets) for the Subsystem Device Driver.
|Table 4. Subsystem Device Driver package file names (also use when running HACMP on concurrent mode on AIX 4.3.3)
(only use when running HACMP on non-concurrent mode on AIX
4.3.3)
|
Package file names
Description
ibmSdd_421.rte
AIX 4.2.1
ibmSdd_432.rte
AIX 4.3.2 or AIX 4.3.3
ibmSdd_433.rte
AIX 4.3.3
The installation package installs a number of major files on your AIX
system.Table 5 lists the major files that are part of the Subsystem Device
Driver installation package.
|Table 5. Major files included in the Subsystem Device Driver installation package
|
Filename
Description
defdpo
Define method of the Subsystem Device Driver pseudo parent data path
optimizer (dpo)
cfgdpo
Configure method of the Subsystem Device Driver pseudo parent dpo
define_vp
Define method of the Subsystem Device Driver vpath devices
cfgvpath
Configure method of Subsystem Device Driver vpath devices
cfallvpath
Fast-path configure method to configure the Subsystem Device Driver
pseudo parent dpo and all vpath devices
vpathdd
The Subsystem Device Driver
hd2vp
The Subsystem Device Driver script that converts an ESS hdisk device
volume group to a Subsystem Device Drive vpath device volume group
vp2hd
The Subsystem Device Driver script that converts a Subsystem Device
Driver vpath device volume group to an ESS hdisk device volume group
datapath
The Subsystem Device Driver driver console command tool
lsvpcfg
The Subsystem Device Driver driver query configuration status command
mkvg4vp
The command that creates a Subsystem Device Driver volume group
extendvg4vp
The command that extends Subsystem Device Driver devices to a Subsystem
Device Driver volume group
dpovgfix
The command that fixes a Subsystem Device Driver volume group that has
mixed vpath and hdisk physical volumes
savevg4vp
The command that backs-up all files belonging to a specified volume group
with Subsystem Device Driver devices.
restvg4vp
The command that restores all files belonging to a specified volume group
with Subsystem Device Driver devices.
The following procedures assume that the Subsystem Device Driver will be used to access all of your single and multipath devices.
|To install the Subsystem Device Driver, use the System Management |Interface Tool (SMIT) . The SMIT facility runs in two interfaces, |nongraphical (type SMITTY to invoke the nongraphical user |interface) or graphical (type SMIT to invoke the graphical user |interface). The Subsystem Device Driver is released as an installation |image. The fileset name is ibmSdd_nnn.rte, where nnn |represents the AIX version level (4.2.1, 4.3.2, or |4.3.3). For example, the fileset name for the AIX |4.3.2 level is ibmSdd_432.rte.
Throughout this SMIT procedure, /dev/cd0 is used for the compact disc drive address. The drive address might be different in your environment. Perform the following SMIT steps to install the Subsystem Device Driver package on your system.
|
+--------------------------------------------------------------------------------+ | ARE YOU SURE?? | | Continuing may delete information you may want to keep. | | This is your last chance to stop before continuing. | +--------------------------------------------------------------------------------+
|You can verify that the Subsystem Device Driver has been |successfully installed by issuing the lslpp -l |ibmSdd_421.rte, lslpp -l ibmSdd_432.rte, or |lslpp -l ibmSdd_433.rte command.
|If you have successfully installed the
|ibmSdd_432.rte package, the output from the lslpp -l
|ibmSdd_432.rte command looks like this:
|+--------------------------------------------------------------------------------+
||Fileset Level State Description |
|| ---------------------------------------------------------------------------- |
||Path: /usr/lib/objrepos |
|| ibmSdd_432.rte 1.2.2.0 COMMITTED IBM Subsystem Device Driver |
|| for AIX V432 & up wo/HACMP |
|| |
||Path: /etc/objrepos |
|| ibmSdd_432.rte 1.2.2.0 COMMITTED IBM Subsystem Device Driver |
|| for AIX V432 & up wo/HACMP |
|+--------------------------------------------------------------------------------+
|If you have successfully installed the
|ibmSdd_433.rte package, the output from the lslpp -l
|ibmSdd_433.rte command looks like this:
|+--------------------------------------------------------------------------------+
||Fileset Level State Description |
|| ---------------------------------------------------------------------------- |
||Path: /usr/lib/objrepos |
|| ibmSdd_433.rte 1.2.2.0 COMMITTED IBM Subsystem Device Driver |
|| for AIX V433 & up w/HACMP |
|| |
||Path: /etc/objrepos |
|| ibmSdd_433.rte 1.2.2.0 COMMITTED IBM Subsystem Device Driver |
|| for AIX V433 & up w/HACMP |
|+--------------------------------------------------------------------------------+
|
The following section describes the steps needed to prepare for and to configure the Subsystem Device Driver.
Before you configure the Subsystem Device Driver, ensure that:
When multiple paths to an ESS device are configured on storage subsystems, ensure that all paths (hdisks) are configured to the Available condition on the AIX host before the Subsystem Device Driver is configured. Otherwise, some Subsystem Device Driver devices will lose multiple-path capability.
Perform the following steps:
Attention: Before you vary off a volume group, unmount all file systems of that volume group that are mounted. If some ESS devices (hdisks) are used as physical volumes of an active volume group, and there are file systems of that volume group being mounted, then you must unmount all file systems, and vary off (deactivate) all active volume groups with ESS Subsystem Device Driver disks.
Perform the following steps to configure the Subsystem Device Driver using SMIT:
To check the Subsystem Device Driver configuration, you can use either the SMIT Display Device Configuration panel or the lsvpcfg console command.
Perform the following steps to verify the configuration of the Subsystem Device Driver on an AIX host system:
If any device is listed as Defined, the configuration was not successful. Check the configuration procedure again. See Configuring the Subsystem Device Driver for information about the procedure.
Perform the following steps to verify that multiple paths are configured for each adapter connected to an ESS port:
If you want to use the command-line interface to verify the configuration, type lsvpcfg.
You should see output similiar to this:
+--------------------------------------------------------------------------------+ |vpath0 (Avail pv vpathvg) 018FA067 = hdisk1 (Avail ) | |vpath1 (Avail ) 019FA067 = hdisk2 (Avail ) | |vpath2 (Avail ) 01AFA067 = hdisk3 (Avail ) | |vpath3 (Avail ) 01BFA067 = hdisk4 (Avail ) hdisk27 (Avail ) | |vpath4 (Avail ) 01CFA067 = hdisk5 (Avail ) hdisk28 (Avail ) | |vpath5 (Avail ) 01DFA067 = hdisk6 (Avail ) hdisk29 (Avail ) | |vpath6 (Avail ) 01EFA067 = hdisk7 (Avail ) hdisk30 (Avail ) | |vpath7 (Avail ) 01FFA067 = hdisk8 (Avail ) hdisk31 (Avail ) | |vpath8 (Avail ) 020FA067 = hdisk9 (Avail ) hdisk32 (Avail ) | |vpath9 (Avail pv vpathvg) 02BFA067 = hdisk20 (Avail ) hdisk44 (Avail ) | |vpath10 (Avail pv vpathvg) 02CFA067 = hdisk21 (Avail ) hdisk45 (Avail ) | |vpath11 (Avail pv vpathvg) 02DFA067 = hdisk22 (Avail ) hdisk46 (Avail ) | |vpath12 (Avail pv vpathvg) 02EFA067 = hdisk23 (Avail ) hdisk47 (Avail ) | |vpath13 (Avail pv vpathvg) 02FFA067 = hdisk24 (Avail ) hdisk48 (Avail ) | +--------------------------------------------------------------------------------+
The IBM Subsystem Device Driver supports path-selection policies that increase the performance of multi-path configured ESSs and make path failures transparent to applications. The following path-selection policies are supported:
The path-selection policy is set at the Subsystem Device Driver device level. The default path-selection policy for a Subsystem Device Driver device is load balancing. You can change the policy for a Subsystem Device Driver device with the chdev command.
Before changing the path-selection policy, determine the active attributes for the Subsystem Device Driver device. Type the lsattr -El vpathN command. Press Enter, where N represents the vpath-number, N=[0,1,2,...]. The output should look similar to this:
+--------------------------------------------------------------------------------+ |pvid 0004379001b90b3f0000000000000000 Data Path Optimizer Parent False | |policy df Scheduling Policy True | |active_hdisk hdisk1/30C12028 Active hdisk False | |active_hdisk hdisk5/30C12028 | +--------------------------------------------------------------------------------+
The path-selection policy is the only attribute of a Subsystem Device Driver device that can be changed. The valid policies are rr, lb, fo, and df. Here are the explanations for these policies:
Attention: By changing a Subsystem Device Driver device's attribute, the chdev command unconfigures and then reconfigures the device. You must ensure the device is not in use if you are going to change its attribute. Otherwise, the command fails.
Use the following command to change the Subsystem Device Driver path-selection policy:
chdev -l vpathN -a policy=[rr/fo/lb/df]
To activate additional paths to a Subsystem Device Driver device, the related Subsystem Device Driver devices must be unconfigured and then reconfigured. The Subsystem Device Driver conversion scripts should be run to enable the necessary Subsystem Device Driver associations and links between the Subsystem Device Driver vpath (pseudo) devices and the ESS hdisk devices.
Perform the following steps from the AIX command line to activate additional paths to a Subsystem Device Driver device:
lspv
Attention: You must fix this problem with the volume group before proceeding to step 3. Otherwise, the volume group loses path failover capability. To fix the problem, type the following command:
dpovgfix vg-nameVg-name represents the volume group.
lsvgfs vg-name
mount
umount mounted-filesystem
vp2hd vg-nameWhen the conversion script completes, the volume group is in the Active condition (varied on).
varyoffvg vg-name
|If you are using SMIT, perform the following steps: |
If you are using SMIT, perform the following steps:
Subsystem Device Driver devices should show two or more hdisks associated with each Subsystem Device Driver device when failover protection is required.
varyonvg vg-name
hd2vp vg-name
Before you unconfigure the Subsystem Device Driver devices, all the file systems belonging to Subsystem Device Driver volume groups must be unmounted. Then, run the vp2hd conversion script to convert the volume group from Subsystem Device Driver devices (vpathN) to ESS subsystem devices (hdisks).
Using the System Management Interface Tool (SMIT), you can unconfigure the Subsystem Device Driver devices in two ways. Either you can unconfigure without deleting the device information from the Object Database Management (ODM) database, or you can delete device information from the ODM database. If you unconfigure without deleting the device information, the device remains in the Defined condition. Using either SMIT or the mkdev -l vpathN command, you can return the device to the Available condition.
If you delete the device information from the ODM database, that device is removed from the system. To return it, follow the procedure described in "Configuring the Subsystem Device Driver".
Perform the following steps to unconfigure the Subsystem Device Driver devices:
Notes:
Before you remove the Subsystem Device Driver package from your AIX host system, all the Subsystem Device Driver devices must be removed from your host system. The fast-path rmdev -dl dpo -R command removes all the Subsystem Device Driver devices from your system. After all Subsystem Device Driver devices are removed, perform the following steps to remove the Subsystem Device Driver.
+--------------------------------------------------------------------------------+ | ARE YOU SURE?? | | Continuing may delete information you may want to keep. | | This is your last chance to stop before continuing. | +--------------------------------------------------------------------------------+
If you are upgrading the Subsystem Device Driver, go to Upgrading the Subsystem Device Driver.
To upgrade the Subsystem Device Driver to a newer version, all the Subsystem Device Driver devices must be removed, and the existing Subsystem Device Driver must be uninstalled. If your application program accesses Subsystem Device Driver devices through AIX LVM, then you have to use Subsystem Device Driver's conversion tools to convert all physical volumes of the Subsystem Device Driver volume groups into ESS hdisks before removing the Subsystem Device Driver. After installing and configuring the newer version of the Subsystem Device Driver, you need to convert these physical volumes back from ESS hdisk devices to Subsystem Device Driver vpath devices.
Perform the following steps to upgrade the Subsystem Device Driver:
rm .tocEnsure that this file is removed because it contains information about the previous version of Subsystem Device Driver or DPO.
lsvgfs vg_name
umount filesystem_name
varyoffvg vg_name
rmdev -dl dpo -R
lsvpcfg
varyonvg vg_name
hd2vp vg_name
Attention: If a Subsystem Device Driver volume group's physical volumes are mixed with hdisk devices and vpath devices, you must run the dpovgfix utility to fix this problem. Otherwise, the Subsystem Device Driver will not function properly. Use the dpovgfix vg_name command to fix this problem.
Concurrent download of licensed internal code is the capability to download and install licensed internal code on an ESS while applications continue to run. This capability is supported for single-path (SCSI only) and multiple-path (SCSI or FCP) access to an ESS.
Attention: During the download of licensed internal code, the AIX error log might overflow and excessive system paging space could be consumed. When the system paging space drops too low it could cause your AIX system to hang. To avoid this problem, you can perform the following steps prior to doing the download:
> errpt > file.save
> errclear 0
/usr/lib/errstop
Once you've completed steps 1- 4, you can perform the download of the ESS licensed internal code. After the download completes, type /usr/lib/errdemon from the command-line interface to restart the AIX error log daemon.
You can now run the Subsystem Device Driver in concurrent and non-concurrent multihost environments in which more than one host is attached to the same LUNs on an ESS. RS/6000 servers running HACMP/6000 in concurrent or non-concurrent mode are supported. Different releases of Subsystem Device Driver support different kinds of environments. (See Table 6 and Table 7.)
HACMP/6000 provides a reliable way for clustered IBM RS/6000 servers which share disk resources to recover from server and disk failures. In a HACMP/6000 environment, each RS/6000 server in a cluster is a node. Each node has access to shared disk resources that are accessed by other nodes. When there is a failure, HACMP/6000 tranfers ownership of shared disks and other resources based on how you define the relationship among nodes in a cluster. This process is known as node failover or node failback. HACMP supports two modes of operation:
The Subsystem Device Driver supports RS/6000 servers connected to shared
disks with SCSI adapters and drives as well as FCP adapters and drives.
The kind of attachment support depends on the version of Subsystem Device
Driver that you have installed. Table 6 summarizes the software requirements to support
HACMP/6000:
|Table 6. Software support for HACMP/6000 in concurrent mode
|
Subsystem Device Driver Version and Release Level
HACMP 4.3.1 + APARs
HACMP 4.4 + APARs
Subsystem Device Driver 1.1.4.0 (SCSI only)
Subsystem Device Driver 1.2.0.0 (SCSI/FCP)
Subsystem Device Driver 1.2.2.0 (SCSI/FCP)
|Table 7. Software support for HAMCP/6000 in nonconcurrent mode
|
Subsystem Device Driver Version and Release Level
HACMP 4.3.1 + APARs
HACMP 4.4 + APARs
Subsystem Device Driver 1.2.2.0 (SCSI/FCP)
Even though the Subsystem Device Driver supports HACMP/6000, certain
combinations of features are not supported. Table 8 lists those combinations:
Table 8. HACMP/6000 and supported Subsystem Device Driver features
| Feature | RS/6000 node running HACMP |
| ESS concurrent code load | Yes |
| Subsystem Device Driver load balancing | Yes |
| SCSI | Yes |
| FCP (fibre) | Yes |
| Single-path fibre | No |
| SCSI and fibre-channel connections to the same LUN from one host (mixed environment) | No |
|What's new in Subsystem Device Driver for HACMP/6000
|The ibmSdd_433.rte fileset for Subsystem Device Driver |v1.2.2.0 has different features compared with |ibmSdd_432.rte fileset for Subsystem Device Driver |v1.2.2.0 release. The ibmSdd_433.rte |fileset implements the SCSI-3 Persistent Reserve command set, in order to |support HACMP in non-concurrent mode with single-point failure |protection. The ibmSdd_433.rte fileset requires the ESS G3 level |microcode on the ESS to support the SCSI-3 Persistent Reserve command |set. If the ESS G3 level microcode is not installed, the |ibmSdd_433.rte fileset switches the multi-path configuration to a |single-path configuration. There is no single-point failure protection |for single-path configurations. |
|The ibmSdd_433.rte fileset has a new attribute under its
|pseudo parent (dpo), that reflects whether the ESS supports the Persistent
|Reserve Command set or not. The attribute name is
|persistent_resv. If the Subsystem Device Driver detects that
|G3 level microcode is installed, the persistent_resv attribute is
|created in the CuAt ODM and its value is set to yes; otherwise
|this attribute only exists in the PdAt ODM and its value is set to
|no (default). You can use the following command to check the
|persistent_resv attribute, after the Subsystem Device Driver device
|configuration is complete:
|odmget -q "name = dpo" CuAt
If your attached ESS has the G3 microcode, the output should look similar to this:
name = "dpo" attribute = "persistent_resv" value = "yes" generic = "D" rep = "sl" nls_index = 0
In order to implement the Persistent Reserve command set, each host server needs a unique 8-byte reservation key. There are 2 ways to get a unique reservation key. In HACMP/6000 environments, HACMP/6000 generates a unique key for each node in the ODM database. When the Subsystem Device Driver cannot find that key in the ODM database, it generates a unique reservation key by using the middle 8 bytes of the output from the uname -m command.
|To check the Persistent Reserve Key of a node, provided by HACMP,
|issue the command:
|odmget -q "name = ioaccess" CuAt
|The output should look similar to this:
| name = "ioaccess"
| attribute = "perservekey"
| value = "01043792"
| type = "R"
| generic = ""
| rep = "s"
| nls_index = 0
|There is a special requirement regarding unconfiguring and removing |the ibmSdd_433.rte fileset for Subsystem Device Driver |v1.2.2.0 vpath devices. You must unconfigure and |remove the vpath devices before you unconfigure and remove the |vpath devices' underlying ESS hdisks. Otherwise if the ESS hdisks |are unconfigured and removed first, the persistent reserve will not be |released, even though the vpath devices have been successfully unconfigured |and removed.
The Subsystem Device Driver does not automatically create the pvid attribute in the ODM database for each vpath device. The AIX disk driver automatically creates the pvid attribute in the ODM database, if a pvid exists on the physical device; however, the Subsystem Device Driver does not. Therefore, the first time you import a new Subsystem Device Driver volume group to a new cluster node, you must import the volume group using hdisks as physical volumes. Next, run the hd2vp conversion script (see Subsystem Device Driver utility programs) to convert the volume group's physical volumes from ESS hdisks to vpath devices. This conversion step not only create pvid attributes for all vpath devices which belong to that imported volume group, it also deletes the pvid attributes for these vpath devices' underlying hdisks. Later on you can import and vary on the volume group directly from the vpath devices. These special requirements apply to both concurrent and non-concurrent volume groups.
Under certain conditions, the state of a physical device's pvid on a system is not always as expected. So it is necessary to determine the state of a pvid as displayed by the lspv command, in order to select the appropriate import volume group action.
|There are four scenarios:
|Scenario 1. lspv displays pvid's for both
|hdisks and vpath:
| >lspv
| hdisk1 003dfc10a11904fa None
| hdisk2 003dfc10a11904fa None
| vpath0 003dfc10a11904fa None
|Scenario 2. lspv displays pvid's for hdisks
|only:
|For both Scenario 1 and Scenario 2, the volume group should be imported
|using the hdisk names and then converted using the hd2vp command:
| >lspv
| hdisk1 003dfc10a11904fa None
| hdisk2 003dfc10a11904fa None
| vpath0 none None
| >importvg -y vg_name -V major# hdisk1
| >hd2vp vg_name
|Scenario 3. lspv displays the pvid for
|vpath only:
|For Scenario 3, the volume group should be imported using the vpath
|name:
| >lspv
| hdisk1 none None
| hdisk2 none None
| vpath0 003dfc10a11904fa None
| >importvg -y vg_name -V major# vpath0
|Scenario 4. lspv does not display the
|pvid on the hdisks or the vpath:
|For Scenario 4, the pvid will need to be placed in the odm for
|the vpath devices and then the volume group can be imported using the vpath
|name:
| >lspv
| hdisk1 none None
| hdisk2 none None
| vpath0 none None
| >chdev -l vpath0 -a pv=yes
| >importvg -y vg_name -V major# vpath0
Normally, when there is a node failure, HACMP/6000 tranfers ownership of shared disks and other resources, through a process known as node failover. Certain situations, such as, a loose or disconnected SCSI or fibre-adapter card, can cause your vpath devices to lose one or more underlying paths during node failover. To recover these paths, you need to first check to ensure that all the underlying paths (hdisks) are in the Available state. Next, you need to unconfigure and reconfigure your Subsystem Device Driver vpath devices.
If your vpath devices have lost one or more underlying paths and they belong to an active volume group, perform the following steps to recovery the lost paths:
Notes:
After you configure the Subsystem Device Driver, it creates Subsystem Device Driver devices (vpath devices) for ESS LUNs. ESS LUNs are accessible through the connection between the AIX host server SCSI or FCP adapter and the ESS ports. The AIX disk driver creates the original or ESS devices (hdisks). Therefore, with Subsystem Device Driver, an application now has two ways in which to access ESS devices.
To use the load balancing and failover features of the Subsystem Device Driver and access ESS devices, your application must use the Subsystem Device Driver vpath devices rather than the ESS hdisk devices.
Two types of applications use ESS disk storage. One type of application accesses ESS devices through the Subsystem Device Driver vpath device (raw device). The other type of application accesses ESS devices through the AIX logical volume manager (LVM). For this type of application, you must create a volume group with the Subsystem Device Driver vpath devices.
The Subsystem Device Driver provides load-balancing and failover protection on AIX for applications and for the LVM when ESS vpath devices are used. These devices must have a minimum of two paths to a physical logical unit number (LUN) for failover protection to exist.
To provide failover protection, an ESS vpath device must include a minimum of two paths. Both the Subsystem Device Driver vpath device and the ESS hdisk devices must all be in the Available condition. In the following example, vpath0, vpath1, and vpath2 all have a single path and, therefore, will not provide failover protection because there is no alternate path to the ESS LUN. The other Subsystem Device Driver vpath devices have two paths and, therefore, can provide failover protection.
To display which ESS vpath devices are available to provide failover protection, use either the Display Data Path Device Configuration SMIT panel, or run the lsvpcfg command. Perform the following steps to use SMIT:
You will see output similar to the following:
Figure 3. Output from the Display Data Path Device Configuration SMIT panel
+--------------------------------------------------------------------------------+ |vpath0 (Avail pv vpathvg) 018FA067 = hdisk1 (Avail ) | |vpath1 (Avail ) 019FA067= hdisk2 (Avail ) | |vpath2 (Avail ) 01AFA067 = hdisk3 (Avail ) | |vpath3 (Avail ) 01BFA067 = hdisk4 (Avail ) hdisk27 (Avail ) | |vpath4 (Avail ) 01CFA067 = hdisk5 (Avail ) hdisk28 (Avail ) | |vpath5 (Avail ) 01DFA067 = hdisk6 (Avail ) hdisk29 (Avail ) | |vpath6 (Avail ) 01EFA067 = hdisk7 (Avail ) hdisk30 (Avail ) | |vpath7 (Avail ) 01FFA067 = hdisk8 (Avail ) hdisk31 (Avail ) | |vpath8 (Avail ) 020FA067 = hdisk9 (Avail ) hdisk32 (Avail ) | |vpath9 (Avail pv vpathvg) 02BFA067 = hdisk20 (Avail ) hdisk44 (Avail ) | |vpath10 (Avail pv vpathvg) 02CFA067 = hdisk21 (Avail ) hdisk45 (Avail ) | |vpath11 (Avail pv vpathvg) 02DFA067 = hdisk22 (Avail ) hdisk46 (Avail ) | |vpath12 (Avail pv vpathvg) 02EFA067 = hdisk23 (Avail ) hdisk47 (Avail ) | |vpath13 (Avail pv vpathvg) 02FFA067 = hdisk24 (Avail ) hdisk48 (Avail ) | +--------------------------------------------------------------------------------+
The following information is displayed:
Example of vpath devices with and without failover protection: Vpath0, vpath1, and vpath2 have only a single path and therefore will not provide failover protection. The other ESS vpath devices each have two paths and thus can provide failover protection. The requirement for failover protection is that the ESS vpath device, and at least two hdisk devices making it up, must be in the Available condition.
Attention: The configuration condition also indicates whether or not the Subsystem Device Driver vpath device is defined to AIX as a physical volume (pv flag). If pv is displayed for both Subsystem Device Driver vpath devices and ESS hdisk devices, you might not have failover protection. Run the dpovgfix command to fix this problem.
You can also use the datapath command to display information about a Subsystem Device Driver vpath device. This command displays the number of paths that the device has. For example, the datapath query device 10 command might produce this output:
+--------------------------------------------------------------------------------+ |DEV#: 10 DEVICE NAME: vpath10 TYPE: 2105B09 SERIAL: 02CFA067 | |================================================================== | |Path# Adapter/Hard Disk State Mode Select Errors | | 0 scsi6/hdisk21 OPEN NORMAL 44 0 | | 1 scsi5/hdisk45 OPEN NORMAL 43 0 | +--------------------------------------------------------------------------------+
The example output shows that device vpath10 has two paths and both are operational.
You can create a volume group with Subsystem Device Driver vpath devices using the Logical Volume Groups SMIT panel. The Subsystem Device Driver vpath devices included in the volume group should be chosen from those that can provide failover protection.
It is possible to create a volume group that has only a single path (see Figure 3) and then add paths later by reconfiguring the ESS. (See Adding paths to a device that is part of a volume group for information about adding paths to a Subsystem Device Driver device.) If you have a physical volume with only a single path, failover protection will not be provided to that Subsystem Device Driver volume group.
To create a new volume group with Subsystem Device Driver vpaths, perform the following steps:
Tip: The SMIT facility runs in two interfaces, nongraphical and graphical. This step uses the nongraphical interface.You can type SMIT to invoke the graphical user interface.
|If you use a script file to create a volume group with Subsystem |Device Driver vpath devices, you must modify your script file and replace the |mkvg command with the mkvg4vp command.
All the functions that apply to a regular volume group also apply to a Subsystem Device Driver volume group. Use SMIT to create a logical volume group (mirrored, striping, or compressed), or a file system (mirrored, striping, or compressed) on a Subsystem Device Driver volume group.
Once you create the volume group, AIX creates the Subsystem Device Driver vpath device as a physical volume (pv). In Figure 3, vpath9 through vpath13 are included in a volume group and they become physical volumes. To list all the physical volumes known to AIX, use the lspv command. Any ESS vpath devices that were created into physical volumes are included in the output. The output should look similar to this:
+--------------------------------------------------------------------------------+ |hdisk0 0001926922c706b2 rootvg | |hdisk1 none None | |... | |hdisk10 none None | |hdisk11 00000000e7f5c88a None | |... | |hdisk48 none None | |hdisk49 00000000e7f5c88a None | |vpath0 00019269aa5bc858 None | |vpath1 none None | |vpath2 none None | |vpath3 none None | |vpath4 none None | |vpath5 none None | |vpath6 none None | |vpath7 none None | |vpath8 none None | |vpath9 00019269aa5bbadd vpathvg | |vpath10 00019269aa5bc4dc vpathvg | |vpath11 00019269aa5bc670 vpathvg | |vpath12 000192697f9fd2d3 vpathvg | |vpath13 000192697f9fde04 vpathvg | +--------------------------------------------------------------------------------+
To display the devices that comprise a volume group, enter the lsvg -p vg-name command. For example, the lsvg -p vpathvg command might produce the following output:
+--------------------------------------------------------------------------------+ |PV_NAME PV STATE TOTAL PPs FREE PPs FREE DISTRIBUTION | |vpath9 active 29 4 00..00..00..00..04 | |vpath10 active 29 4 00..00..00..00..04 | |vpath11 active 29 4 00..00..00..00..04 | |vpath12 active 29 4 00..00..00..00..04 | |vpath13 active 29 28 06..05..05..06..06 | +--------------------------------------------------------------------------------+
The example output indicates that the vpathvg volume group uses
physical volumes vpath9 through vpath13.
|You can import a new volume group definition from a set of physical volumes
|with Subsystem Device Driver vpath devices using the Volume Groups SMIT
|panel.
|Attention:
|The Subsystem Device Driver does not automatically create the pvid
| attribute in the ODM database for each vpath device. The AIX
|disk driver automatically creates the pvid attribute in the ODM
|database, if a pvid exists on the physical device; however,
|the Subsystem Device Driver does not. Therefore, the first time you
|import a new Subsystem Device Driver volume group to a new cluster node, you
|must import the volume group using hdisks as physical volumes. Next,
|run the hd2vp conversion script (see Subsystem Device Driver utility programs) to convert the volume group's physical volumes from
|ESS hdisks to vpath devices. This conversion step not only create
|pvid attributes for all vpath devices which belong to that
|imported volume group, it also deletes the pvid attributes for
|these vpath devices' underlying hdisks. Later on you can import
|and vary on the volume group directly from the vpath devices. These
|special requirements apply to both concurrent and non-concurrent volume
|groups.
|Under certain conditions, the state of a pvid on a system is not
|always as we expected. So it is necessary to determine the state of a
|pvid as displayed by the lsvp command, in order to select the
|appropriate action.
|There are four scenarios:
|Scenario 1. lspv displays pvid's for both hdisks and
|vpath:
|Scenario 2. lspv displays pvid's for hdisks
|only:
|For both Scenario 1 and Scenario 2, the volume group should be imported
|using the hdisk names and then converted using the hd2vp command:
|Scenario 3. lspv displays the pvid for vpath
|only:
|For Scenario 3, the volume group should be imported using the vpath
|name:
|Scenario 4. lspv does not display the pvid on
|the hdisks or the vpath:
|For Scenario 4, the pvid will need to be placed in the odm for
|the vpath devices and then the volume group can be imported using the vpath
|name:
|See "Special requirements" for special requirements regarding unconfiguring and removing
|the ibmSdd_433.rte fileset for Subsystem Device DriverSubsystem Device
|Driver v1.2.2.0 vpath devices.
|
|To import a volume group with Subsystem Device Driver devices, follow these
|steps:
| |Tip: The SMIT facility runs in two interfaces,
|nongraphical and graphical. This step uses the nongraphical
|interface.You can type SMIT to invoke the graphical user
|interface.
|You can use the F4 key to get a choice list.
| |You can export a volume group definition from a set of physical volumes
|with Subsystem Device Driver vpath devices using the Volume Groups SMIT
|panel.
|The exportvg command removes the definition of the volume group specified
|by the VolumeGroup parameter from the system. Since all system
|knowledge of the volume group and its contents are removed, an exported volume
|group can no longer be accessed. The exportvg command does not modify
|any user data in the volume group.
|A volume group is a nonshared resource within the system; it should
|not be accessed by another system until it has been explicitly exported from
|its current system and imported on another. The primary use of the
|exportvg command, coupled with the importvg command, is to allow portable
|volumes to be exchanged between systems. Only a complete volume group
|can be exported, not individual physical volumes.
|Using the exportvg command and the importvg command, you can also switch
|ownership of data on physical volumes shared between two systems.
|To export a volume group with Subsystem Device Driver devices, follow these
|steps:
| |Tip: The SMIT facility runs in two interfaces,
|nongraphical and graphical. This step uses the nongraphical
|interface.You can type SMIT to invoke the graphical user
|interface.
|You can use the F4 key to select which volume group you want to
|export.|Importing a volume group with Subsystem Device Driver
|
| >lspv
| hdisk1 003dfc10a11904fa None
| hdisk2 003dfc10a11904fa None
| vpath0 003dfc10a11904fa None
| >lspv
| hdisk1 003dfc10a11904fa None
| hdisk2 003dfc10a11904fa None
| vpath0 none None
| >importvg -y vg_name -V major# hdisk1
| >hd2vp vg_name
| >lspv
| hdisk1 none None
| hdisk2 none None
| vpath0 003dfc10a11904fa None
| >importvg -y vg_name -V major# vpath0
| >lspv
| hdisk1 none None
| hdisk2 none None
| vpath0 none None
| >chdev -l vpath0 -a pv=yes
| >importvg -y vg_name -V major# vpath0
|Exporting a volume group with Subsystem Device Driver
|
AIX can only create volume groups from disk (or pseudo) devices that are physical volumes. If a volume group is created using a device that is not a physical volume, AIX makes it a physical volume as part of the procedure of creating the volume group. A physical volume has a physical volume identifier (pvid) written on its sector 0 and also has a pvid attribute attached to the device attributes in the CuAt ODM. The lspv command can be used to list all the physical volumes known to AIX. Here is sample output from this command:
+--------------------------------------------------------------------------------+ |hdisk0 0001926922c706b2 rootvg | |hdisk1 none None | |... | |hdisk10 none None | |hdisk11 00000000e7f5c88a None | |... | |hdisk48 none None | |hdisk49 00000000e7f5c88a None | |vpath0 00019269aa5bc858 None | |vpath1 none None | |vpath2 none None | |vpath3 none None | |vpath4 none None | |vpath5 none None | |vpath6 none None | |vpath7 none None | |vpath8 none None | |vpath9 00019269aa5bbadd vpathvg | |vpath10 00019269aa5bc4dc vpathvg | |vpath11 00019269aa5bc670 vpathvg | |vpath12 000192697f9fd2d3 vpathvg | |vpath13 000192697f9fde04 vpathvg | +--------------------------------------------------------------------------------+
In some cases, access to data is not lost, but failover protection might not be present. Failover protection can be lost in several ways:
The following sections provide more information about the ways that failover protection can be lost.
Due to hardware errors, the Subsystem Device Driver may remove one or more paths to a vpath pseudo device. Once the point is reached where only one path remains, failover protection for the pseudo devices no longer exists. The datapath query device command can be used to show the state of paths to a pseudo device. Any path whose condition is shown as Dead can no longer be used for I/O operations.
A volume group created using any single-path pseudo devices does not have failover protection because there is no alternate path to the ESS LUN.
It is possible to modify attributes for an hdisk device by running the chdev command. The chdev command invokes the hdisk configuration method to make the requested change. In addition, the hdisk configuration method sets the pvid attribute for an hdisk if it determines that the hdisk has a pvid written on sector 0 of the LUN. This causes the vpath pseudo device and one or more of its hdisks to have the same pvid attribute in the ODM. If the volume group containing the vpath pseudo device is now activated, the LVM uses the first device it finds in the ODM with the desired pvid to activate the volume group.
As an example, if you issue the lsvpcfg command, the following output is displayed:
+--------------------------------------------------------------------------------+ |vpath0 (Avail pv vpathvg) 018FA067 = hdisk1 (Avail ) | |vpath1 (Avail ) 019FA067 = hdisk2 (Avail ) | |vpath2 (Avail ) 01AFA067 = hdisk3 (Avail ) | |vpath3 (Avail ) 01BFA067 = hdisk4 (Avail ) hdisk27 (Avail ) | |vpath4 (Avail ) 01CFA067 = hdisk5 (Avail ) hdisk28 (Avail ) | |vpath5 (Avail ) 01DFA067 = hdisk6 (Avail ) hdisk29 (Avail ) | |vpath6 (Avail ) 01EFA067 = hdisk7 (Avail ) hdisk30 (Avail ) | |vpath7 (Avail ) 01FFA067 = hdisk8 (Avail ) hdisk31 (Avail ) | |vpath8 (Avail ) 020FA067 = hdisk9 (Avail ) hdisk32 (Avail ) | |vpath9 (Avail pv vpathvg) 02BFA067 = hdisk20 (Avail ) hdisk44 (Avail ) | |vpath10 (Avail pv vpathvg) 02CFA067 = hdisk21 (Avail ) hdisk45 (Avail ) | |vpath11 (Avail pv vpathvg) 02DFA067 = hdisk22 (Avail ) hdisk46 (Avail ) | |vpath12 (Avail pv vpathvg) 02EFA067 = hdisk23 (Avail ) hdisk47 (Avail ) | |vpath13 (Avail pv vpathvg) 02FFA067 = hdisk24 (Avail ) hdisk48 (Avail ) | +--------------------------------------------------------------------------------+
The following example of a chdev command could also set the pvid attribute for an hdisk:
chdev -l hdisk46 -a queue_depth=30
For this example, the output of the lsvpcfg command would look similar to this:
+--------------------------------------------------------------------------------+ |vpath0 (Avail pv vpathvg) 018FA067 = hdisk1 (Avail ) | |vpath1 (Avail ) 019FA067 = hdisk2 (Avail ) | |vpath2 (Avail ) 01AFA067 = hdisk3 (Avail ) | |vpath3 (Avail ) 01BFA067 = hdisk4 (Avail ) hdisk27 (Avail ) | |vpath4 (Avail ) 01CFA067 = hdisk5 (Avail ) hdisk28 (Avail ) | |vpath5 (Avail ) 01DFA067 = hdisk6 (Avail ) hdisk29 (Avail ) | |vpath6 (Avail ) 01EFA067 = hdisk7 (Avail ) hdisk30 (Avail ) | |vpath7 (Avail ) 01FFA067 = hdisk8 (Avail ) hdisk31 (Avail ) | |vpath8 (Avail ) 020FA067 = hdisk9 (Avail ) hdisk32 (Avail ) | |vpath9 (Avail pv vpathvg) 02BFA067 = hdisk20 (Avail ) hdisk44 (Avail ) | |vpath10 (Avail pv vpathvg) 02CFA067 = hdisk21 (Avail ) hdisk45 (Avail ) | |vpath11 (Avail pv vpathvg) 02DFA067 = hdisk22 (Avail ) hdisk46 (Avail pv vpathvg| |vpath12 (Avail pv vpathvg) 02EFA067 = hdisk23 (Avail ) hdisk47 (Avail ) | |vpath13 (Avail pv vpathvg) 02FFA067 = hdisk24 (Avail ) hdisk48 (Avail ) | +--------------------------------------------------------------------------------+
The output of the lsvpcfg command shows that vpath11 contains hdisk22 and hdisk46. However, hdisk46 is the one with the pv attribute set. If you run the lsvg -p vpathvg command again, you might see something like this:
+--------------------------------------------------------------------------------+ |vpathvg: | |PV_NAME PV STATE TOTAL PPs FREE PPs FREE DISTRIBUTION | |vpath10 active 29 4 00..00..00..00..04 | |hdisk46 active 29 4 00..00..00..00..04 | |vpath12 active 29 4 00..00..00..00..04 | |vpath13 active 29 28 06..05..05..06..06 | +--------------------------------------------------------------------------------+
Notice that now device vpath11 has been replaced by hdisk46. That is because hdisk46 is one of the hdisk devices included in vpath11 and it has a pvid attribute in the ODM. In this example, the LVM used hdisk46 instead of vpath11 when it activated volume group vpathvg. The volume group is now in a mixed mode of operation because it partially uses vpath pseudo devices and partially uses hdisk devices. This is a problem that must be fixed because failover protection is effectively disabled for the vpath11 physical volume of the vpathvg volume group.
If a system is restored from a mksysb restore file or tape, the vpath pseudo device pvid attribute is not set. All logical volumes made up of vpath pseudo devices use hdisk devices instead of vpath devices. This can be rectified by using the hd2vp shell script to convert the volume group back to using vpath devices.
Assume for example that vpath3 is made up of hdisk4 and hdisk27 and that vpath3 is currently a physical volume. If the vpath3, hdisk4, and hdisk27 devices are all deleted by using the rmdev command and then cfgmgr is invoked at the command line, only one path of the original vpath3 is configured by AIX. The following commands would produce this situation:
rmdev -dl vpath3 rmdev -dl hdisk4 rmdev -dl hdisk27 cfgmgr
The datapath query device command displays the vpath3 configuration status.
Next, all paths to the vpath must be restored. You can restore the paths in one of the following ways:
Tip: Running the AIX configuration manager (cfgmgr) n times for n-path configurations of ESS devices is not always required. It depends on whether the ESS device has been used as a physical volume of a volume group or not. If it has, it is necessary to run cfgmgr n times for a n-path configuration. Since the ESS device has been used as a physical volume of a volume group before, it has a pvid value written on its sector 0. When the first SCSI or fibre adapter is configured by cfgmgr, the AIX disk driver configuration method creates a pvid attribute in the AIX ODM database with the pvid value it read from the device. It then creates a logical name (hdiskN), and puts the hdiskN in the Defined condition. When the second adapter is configured, the AIX disk driver configuration method reads the pvid from the same device again, and searches the ODM database to see if there is already a device with the same pvid in the ODM. If there is a match, and that hdiskN is in a Defined condition, the AIX disk driver configuration method does not create another hdisk logical name for the same device. That is why only one set of hdisks gets configured the first time cfgmgr runs. When cfgmgr runs for the second time, the first set of hdisks are in the Available condition, so a new set of hdisks are Defined and configured to the Available condition. That is why you must run cfgmgr n times to get n paths configured. If the ESS device has never belonged to a volume group, that means there is no pvid written on its sector 0. In that case, you only need to run cfgmgr once to get all multiple paths configured.
If you run the cfgmgr command instead of restarting the system after all the ESS hdisk devices are restored, you must unconfigure all Subsystem Device Driver devices to the Defined condition. Then reconfigure the Subsystem Device Driver devices to the Available condition in order to restore all paths to the Subsystem Device Driver (vpath) devices.
The following command shows an example of how to unconfigure a Subsystem Device Driver device to the Defined condition using the command-line interface:
rmdev -l vpathN
The following command shows an example of how to unconfigure all Subsystem Device Driver devices to the Defined condition using the command-line interface:
rmdev -l dpo -R
The following command shows an example of how to configure a vpath device to the Available condition using the command-line interface:
mkdev -l vpathN
The following command shows an example of how to configure all vpath devices to the Available condition using the SMIT:
smitty device
|The following command shows an example of how to configure all vpath
|devices to the Available condition using the command-line interface:
|cfallvpath
Run the dpovgfix shell script to recover a mixed volume group. The syntax is dpovgfix vg-name. The script tries to find a pseudo device corresponding to each hdisk in the volume group and replaces the hdisk with the vpath pseudo device. In order for the shell script to be executed, all mounted file systems of this volume group have to be unmounted. After successful completion of the dpovgfix shell script, mount the file systems again.
You can extend a volume group with Subsystem Device Driver vpath devices using the Logical Volume Groups SMIT panel. The Subsystem Device Driver vpath devices to be added to the volume group should be chosen from those that can provide failover protection. It is possible to add a Subsystem Device Driver vpath device to a Subsystem Device Driver volume group that has only a single path (vpath0 in Figure 3) and then add paths later by reconfiguring the ESS. With a single path, failover protection is not provided. (See Adding paths to a device that is part of a volume group for information about adding paths to a Subsystem Device Driver device.)
To extend a volume group with Subsystem Device Driver devices, follow these steps:
Tip: The SMIT facility runs in two interfaces, nongraphical and graphical. This step uses the nongraphical interface.You can type SMIT to invoke the graphical user interface.
If you use a script file to extend an existing Subsystem Device Driver
volume group, you must modify your script file and replace the
extendvg command with the extendvg4vp
command.
|You can backup all files belonging to a specified volume group with
|Subsystem Device Driver vpath devices using the Volume Groups SMIT
|panel.
|To backup a volume group with Subsystem Device Driver devices, go to Accessing the Back Up a Volume Group with Data Path Devices SMIT panel.
|If you use a script file to back-up all files belonging to a specified
|Subsystem Device Driver volume group, you must modify your script file and
|replace the
|
|
|savevg command with the savevg4vp command.
|Attention: Backing-up files (running the savevg4vp
|command) will result in the loss of all material previously stored on the
|selected output medium. Data integrity of the archive may be
|compromised if a file is modified during system backup. Keep system
|activity at a minimum during the system backup procedure.
|You can restore all files belonging to a specified volume group with
|Subsystem Device Driver vpath devices using the Volume Groups SMIT
|panel.
|To restore a volume group with Subsystem Device Driver devices and go to Accessing the Remake a Volume Group with Data Path Devices SMIT panel.
|If you use a script file to restore all files belonging to a specified
|Subsystem Device Driver volume group, you must modify your script file and
|replace the
|
|
|restvg command with the restvg4vp command. |The Subsystem Device Driver supports several special SMIT panels.
|Some SMIT panels provide Subsystem Device Driver specific functions, while
|other SMIT panels provide AIX functions (but requires the Subsystem Device
|Driver specific commands). For example, the "Add a volume group with
|data path devices" function uses the Subsystem Device Driver
|mkvg4vp command, instead of the AIX mkvg command.
|Table 9 lists the Subsystem Device Driver specific SMIT panels and
|how you should proceed.
|Table 9. Subsystem Device Driver specific SMIT panels and how to proceed |To access the Display Data Path Device Configuration panel, perform the
|following steps:
| |Tip: The SMIT facility runs in two interfaces,
|nongraphical and graphical. This step uses the nongraphical
|interface.You can type SMIT to invoke the graphical user
|interface.
|To access the Display Data Path Device Status panel, perform the following
|steps:
| |Tip: The SMIT facility runs in two interfaces,
|nongraphical and graphical. This step uses the nongraphical
|interface.You can type SMIT to invoke the graphical user
|interface.
|To access the Display Data Path Device Status panel, perform the following
|steps:
| |Tip: The SMIT facility runs in two interfaces,
|nongraphical and graphical. This step uses the nongraphical
|interface.You can type SMIT to invoke the graphical user
|interface.
|To access the Define and Configure All Data Path Devices panel, perform the
|following steps:
| |Tip: The SMIT facility runs in two interfaces,
|nongraphical and graphical. This step uses the nongraphical
|interface.You can type SMIT to invoke the graphical user
|interface.
|To access the Configure a Defined Data Path Device panel, perform the
|following steps:
| |Tip: The SMIT facility runs in two interfaces,
|nongraphical and graphical. This step uses the nongraphical
|interface.You can type SMIT to invoke the graphical user
|interface.
|To access the Remove a Data Path Device panel, perform the following
|steps:
| |Tip: The SMIT facility runs in two interfaces,
|nongraphical and graphical. This step uses the nongraphical
|interface.You can type SMIT to invoke the graphical user
|interface.
|To access the Add a volume group with data path devices panel, perform the
|following steps:
| |Tip: The SMIT facility runs in two interfaces,
|nongraphical and graphical. This step uses the nongraphical
|interface.You can type SMIT to invoke the graphical user
|interface.
|To access the Add a Data Path Volume to a Volume Group panel, perform the
|following steps:
| |Tip: The SMIT facility runs in two interfaces,
|nongraphical and graphical. This step uses the nongraphical
|interface.You can type SMIT to invoke the graphical user
|interface.
|To access the Remove a copy from a datapath Logical Volume panel, perform
|the following steps:
| |Tip: The SMIT facility runs in two interfaces,
|nongraphical and graphical. This step uses the nongraphical
|interface.You can type SMIT to invoke the graphical user
|interface.
|To access the Back Up a Volume Group with Data Path Devices panel and to
|backup a volume group with Subsystem Device Driver devices, perform the
|following steps:
| |Tip: The SMIT facility runs in two interfaces,
|nongraphical and graphical. This step uses the nongraphical
|interface.You can type SMIT to invoke the graphical user
|interface.
|Tip: You can also use the F4 key to list all the available
|Subsystem Device Driver devices, and you can select the devices or files you
|want to backup.
|Attention: Backing-up files (running the savevg4vp
|command) will result in the loss of all material previously stored on the
|selected output medium. Data integrity of the archive may be
|compromised if a file is modified during system backup. Keep system
|activity at a minimum during the system backup procedure.
| |To access the Remake a Volume Group with Data Path Devices panel and
|restore a volume group with Subsystem Device Driver devices, perform the
|following steps:
| |Tip: The SMIT facility runs in two interfaces,
|nongraphical and graphical. This step uses the nongraphical
|interface.You can type SMIT to invoke the graphical user
|interface.
|Backing-up all files belonging to a Subsystem Device Driver volume group
|
|Restoring all files belonging to a Subsystem Device Driver volume group
|
|Subsystem Device Driver specific SMIT panels
|
|Accessing the Display Data Path Device Configuration SMIT panel
|
|Accessing the Display Data Path Device Status SMIT panel
|
|Accessing the Display Data Path Device Adapter Status SMIT panel
|
|Accessing the Define and Configure All Data Path Devices SMIT panel
|
|Accessing the Configure a Defined Data Path Device SMIT panel
|
|Accessing the Remove a Data Path Device SMIT panel
|
|Accessing the Add a Volume Group with Data Path Devices SMIT panel
|
||Accessing the Add a Data Path Volume to a Volume Group SMIT panel
|
|Accessing the Remove a copy from a datapath Logical Volume SMIT panel
|
|Accessing the Back Up a Volume Group with Data Path Devices SMIT panel
|
|
|Accessing the Remake a Volume Group with Data Path Devices SMIT panel
|
|
The Subsystem Device Driver provides two conversion scripts, hd2vp and vp2hd. The hd2vp script converts a volume group from original ESS hdisks into Subsystem Device Driver vpaths, and the vp2hd script converts a volume group from Subsystem Device Driver vpaths into ESS hdisks. Use the vp2hd program when you want to configure your applications back to original ESS hdisks, or when you want to remove the Subsystem Device Driver from your AIX host system.
The syntax for these conversion scripts is as follows:
hd2vp vgname vp2hd vgname
These two conversion programs require that a volume group contain either all original ESS hdisks or all Subsystem Device Driver vpaths. The program fails if a volume group contains both kinds of device special files (mixed volume group).
Tip: Always use SMIT to create a volume group of Subsystem Device Driver devices. This avoids the problem of a mixed volume group.
You can use the dpovgfix script tool to recover mixed volume groups.
Performing AIX system management operations on adapters and ESS hdisk devices might cause original ESS hdisks to be contained within a Subsystem Device Driver volume group. This is known as a mixed volume group. Mixed volume groups happen when a Subsystem Device Driver volume group is inactivated (varied off), and certain AIX commands to the hdisk put the pvid attribute of hdisk back into the ODM database. The following is an example of a command that does this:
chdev -1 hdiskN -a queue_depth=30
If this disk is an active hdisk of a vpath that belongs to a Subsystem Device Driver volume group, and you run the varyonvg command to activate this Subsystem Device Driver volume group, LVM might pick up the hdisk device rather than the vpath device. The result is that a Subsystem Device Driver volume group partially uses Subsystem Device Driver vpath devices, and partially uses ESS hdisk devices. The result is the volume group loses path failover capability for that physical volume. The dpovgfix script tool fixes this problem. The command syntax is:
dpovgfix vg-name
You can use the lsvpcfg script tool to display the configuration status of the Subsystem Device Driver devices. This displays the configuration status for all Subsystem Device Driver devices. The lsvpcfg command can be issued in two ways.
lsvpcfg
See Verifying the Subsystem Device Driver configuration for an example of the output and what it means.
lsvpcfg vpathN0 vpathN1 vpathN2
You will see output similar to this:
+--------------------------------------------------------------------------------+ |vpath10 (Avail pv ) 13916392 = hdisk95 (Avail ) hdisk179 (Avail ) | |vpath20 (Avail ) 02816392 = hdisk23 (Avail ) hdisk106 (Avail ) | |vpath30 (Avail ) 10516392 = hdisk33 (Avail ) hdisk116 (Avail ) | +--------------------------------------------------------------------------------+
See Verifying the Subsystem Device Driver configuration for an explanation of the output.
|You can use the mkvg4vp command to create a Subsystem Device Driver volume |group. For more information about this command, go to section Configuring a volume group for failover protection. |
|You can use the extendvg4vp command to extend an existing Subsystem Device |Driver volume group. For more information about this command, go to |section Extending an existing Subsystem Device Driver volume group. |
If your application used ESS hdisk device special files directly before installing the Subsystem Device Driver, convert it to using the Subsystem Device Driver vpath device special files. After installing the Subsystem Device Driver, perform the following steps:
Tip: The SMIT facility runs in two interfaces, nongraphical and graphical. This step uses the nongraphical interface.You can type SMIT to invoke the graphical user interface.
Attention:
If your application accesses ESS devices through LVM, determine the volume group that it uses before you convert volume groups. Then, perform the following steps to convert the volume group from the original ESS device hdisks to the Subsystem Device Driver vpaths:
To determine the file systems, perform the following steps:
hd2vp vgname
When the conversion is complete, your application now accesses ESS physical LUNs through Subsystem Device Driver vpath devices. This provides load balancing and failover protection for your application.
Before you migrate your non-Subsystem Device Driver volume group to a Subsystem Device Driver volume group, make sure that the following things have been done:
|lslpp -l ibmSdd_421.rte, lslpp -l ibmSdd_432.rte, lslpp -l ibmSdd_433.rte
|An example of output from the lslpp command is:
|+--------------------------------------------------------------------------------+ | ||Fileset Level State Description | || ---------------------------------------------------------------------------- | ||Path: /usr/lib/objrepos | || ibmSdd_432.rte 1.2.2.0 COMMITTED IBM Subsystem Device Driver | || for AIX V432 & up wo/HACMP | || | ||Path: /etc/objrepos | || ibmSdd_432.rte 1.2.2.0 COMMITTED IBM Subsystem Device Driver | || for AIX V432 & up wo/HACMP | |+--------------------------------------------------------------------------------+
Tip: The SMIT facility runs in two interfaces, nongraphical and graphical. This step uses the nongraphical interface.You can type SMIT to invoke the graphical user interface.
chdev -l hdiskN -a pv=clear chdev -l vpathN -a pv=clear
Attention: Exercise care when clearing a pvid from a device with this command. Issuing this command to a device, that does belong to an existing volume group can cause system failures.
You should complete the following steps to migrate a non-Subsystem Device Driver volume group to a multipath Subsystem Device Driver volume group in concurrent mode:
Tip: The SMIT facility runs in two interfaces, nongraphical and graphical. This step uses the nongraphical interface.You can type SMIT to invoke the graphical user interface.
smitty mklvcopy
Use the new Subsystem Device Driver vpath devices for copying all logical volumes. Do not forget to include JFS log volumes.
smitty syncvg
There are two options on the smitty menu:
The fast way to synchronize logical volumes is to select the Synchronize by Physical Volume option.
smitty rmlvcopy
smitty reducevg
The Remove a Physical Volume panel is displayed. Remove all non-Subsystem Device Driver devices.
Notes:
This procedure shows how to migrate an existing AIX volume group to use Subsystem Device Driver vpath (pseudo) devices that have multipath capability. You do not take the volume group out of service. The example shown starts with a volume group, vg1, made up of one ESS device, hdisk13.
Tip: This procedure uses the System Management Interface Tool (SMIT). The SMIT facility runs in two interfaces, nongraphical (type SMITTY to invoke the nongraphical user interface) or graphical (type SMIT to invoke the graphical user interface).
To perform the migration, you must have vpath devices available that are greater than or equal to the size of each of the hdisks making up the volume group. In this example, we have a pseudo device, vpath12, with two paths, hdisk14 and hdisk30, that we will migrate the volume group to.
You can also enter the command:
extendvg4vp -f vg1 vpath12
You can also enter the command:
mirrorvg vg1 vpath12
syncvg -p hdisk13 vpath12
|rmlvcopy loglv01 |1 hdisk13 and rmlvcopy lv01 1 hdisk13
reducevg vg1 hdisk13
The Subsystem Device Driver supports AIX trace functions. The trace ID for the Subsystem Device Driver is 2F8. Trace ID 2F8 traces routine entry, exit, and error paths of the algorithm. To use it, manually turn on the trace function before the program starts to run, then turn off the trace function either after the program stops, or any time you need to read the trace report. To start the trace function, type:
trace -a -j 2F8
To stop the trace function, type:
trcstop
To read the report, type:
trcrpt | pg
The Subsystem Device Driver logs error conditions into the AIX errlog system. To check if the Subsystem Device Driver generated an error log message, type the following command:
errpt -a | grep VPATH
The following list shows the Subsystem Device Driver error log messages and explains each one:
| |The following list shows the new and modified error log messages in |ibmSdd_ibm433.rte fileset for Subsystem Device Driver |v1.2.2.0. This release of Subsystem Device Driver |is for HACMP environments only. See What's new in Subsystem Device Driver for HACMP/6000 for more information on this release. |
Figure 4. Where the Subsystem Device Driver fits in the protocol stack
This chapter provides instructions for installing and configuring the IBM Subsystem Device Driver on an Windows NT host system attached to an ESS. For updated and additional information not included in this chapter, see the README file on the compact disc or visit the Subsystem Device Driver Web site at: www.ibm.com/storage/support/techsup/swtechsup.nsf/support/sddupdates
Notes:
The successful installation and operation of the Subsystem Device Driver involves the following hardware and software components:
To successfully install the Subsystem Device Driver, your Windows NT host system should be an Intel-based system with Windows NT Version 4.0 Service Pack 3 or higher installed. The host system can be a uni-processor or a multi-processor system.
To successfully install the Subsystem Device Driver, ensure that your host system is configured to the ESS as an Intel-based PC (personal computer) server with Windows NT 4.0 or higher.
To use the Subsystem Device Driver SCSI support, ensure your host system meets the following requirements:
To use the Subsystem Device Driver fibre support, ensure your host system meets the following requirements:
The following environments are not supported by the Subsystem Device Driver:
Before you install the Subsystem Device Driver, configure your ESS for single-port or multiple-port access for each LUN. The Subsystem Device Driver requires a minimum of two independent paths that share the same LUN to use the load-balancing and failover features.
For information about configuring your ESS, see IBM Enterprise Storage Server Introduction and Planning Guide, GC26-7294.
Attention: Failure to disable the BIOS of attached non-boot devices may cause your system to attempt boot from an unexpected non-boot device.
Before you install and use the Subsystem Device Driver, you must configure your SCSI adapters. For SCSI adapters that attach boot devices, ensure that the BIOS for the adapter is enabled. For all other adapters that attach non-boot devices, ensure the BIOS for the adapter is disabled.
Unlike SCSI adapters, there are no special configuration requirements for fibre-channel adapters attached to Windows NT host systems.
To install all components, you must have 1 MB (MB equals approximately 1 000 000 bytes) of disk space available, and you must have Windows NT 4.0 Service Pack 3 or higher installed on your system.
You must have root access and you must log on as an administrator user to install the Subsystem Device Driver.
Perform the following steps to install the Subsystem Device Driver filter and application programs on your system:
|To uninstall the Subsystem Device Driver on a Windows NT host system, |perform the following steps: |
|Attention: After uninstalling the previous version, you must |immediately install the new version of Subsystem Device Driver to |avoid any potential data loss (See Installing the Subsystem Device Driver for instructions). |
|You can display the current version of the Subsystem Device Driver on a |Windows NT host system by viewing the sddpath.sys file |properties. To view the properties of sddpath.sys |file, perform the following steps: |
If you attempt to install the Subsystem Device Driver over an existing version of Subsystem Device Driver or Data Path Optimizer (DPO), the installation fails. You must uninstall any previous version of the Subsystem Device Driver or DPO before installing a new version of the Subsystem Device Driver.
Perform the following steps to upgrade to a newer version of the Subsystem Device Driver:
|Attention: After uninstalling the previous version, you must |immediately install the new version of Subsystem Device Driver to |avoid any potential data loss.
To activate the Subsystem Device Driver, you need to restart your Windows NT system after it is installed. In fact, a restart is required to activate multipath support whenever a new file system or partition is added.
|Attention: Ensure that the Subsystem Device Driver is |installed before you add a new path to a device. Otherwise, |the Windows NT server's ability to access existing data on that device |could be lost.
|This section contains the procedures for adding paths to Subsystem Device |Driver in multipath environments. These procedures include: |
|Before adding any additional hardware, you should review the configuration |information for the adapters and devices currently on your Windows NT |server.
|You should verify that the number of adapters and the number of paths to |each ESS volume match the known configuration. Perform the following |steps to display information about the adapters and devices: |
|+--------------------------------------------------------------------------------+ || | ||Active Adapters :1 | || | ||Adpt# Adapter Name State Mode Select Errors Paths Active | || 0 Scsi Port6 Bus0 NORMAL ACTIVE 542 0 10 10 | || | || | |+--------------------------------------------------------------------------------+
|+--------------------------------------------------------------------------------+ || | ||Total Devices : 10 | || | ||DEV#: 0 DEVICE NAME: Disk2 Part0 TYPE: 2105E20 SERIAL: 00A12028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk2 Part0 OPEN NORMAL 14 0 | || | ||DEV#: 1 DEVICE NAME: Disk2 Part1 TYPE: 2105E20 SERIAL: 00A12028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk2 Part1 OPEN NORMAL 94 0 | || | ||DEV#: 2 DEVICE NAME: Disk3 Part0 TYPE: 2105E20 SERIAL: 00B12028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk3 Part0 OPEN NORMAL 16 0 | || | ||DEV#: 3 DEVICE NAME: Disk3 Part1 TYPE: 2105E20 SERIAL: 00B12028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk3 Part1 OPEN NORMAL 94 0 | || | ||DEV#: 4 DEVICE NAME: Disk4 Part0 TYPE: 2105E20 SERIAL: 00D12028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk4 Part0 OPEN NORMAL 14 0 | || | ||DEV#: 5 DEVICE NAME: Disk4 Part1 TYPE: 2105E20 SERIAL: 00D12028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk4 Part1 OPEN NORMAL 94 0 | || | ||DEV#: 6 DEVICE NAME: Disk5 Part0 TYPE: 2105E20 SERIAL: 50812028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk5 Part0 OPEN NORMAL 14 0 | || | ||DEV#: 7 DEVICE NAME: Disk5 Part1 TYPE: 2105E20 SERIAL: 50812028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk5 Part1 OPEN NORMAL 94 0 | || | ||DEV#: 8 DEVICE NAME: Disk6 Part0 TYPE: 2105E20 SERIAL: 60012028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk6 Part0 OPEN NORMAL 14 0 | || | ||DEV#: 9 DEVICE NAME: Disk6 Part1 TYPE: 2105E20 SERIAL: 60012028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk6 Part1 OPEN NORMAL 94 0 | || | |+--------------------------------------------------------------------------------+|
|Perform the following steps to install and configure additional paths to a |vpath device: |
|After installing additional paths to Subsystem Device Driver devices, you |should verify: |
|Perform the following steps to verify that the additional paths have been |installed correctly: |
|+--------------------------------------------------------------------------------+ ||Active Adapters :2 | || | ||Adpt# Adapter Name State Mode Select Errors Paths Active | || 0 Scsi Port6 Bus0 NORMAL ACTIVE 188 0 10 10 | || 1 Scsi Port7 Bus0 NORMAL ACTIVE 204 0 10 10 | || | || | |+--------------------------------------------------------------------------------+
|+--------------------------------------------------------------------------------+ || | || | ||Total Devices : 10 | || | ||DEV#: 0 DEVICE NAME: Disk2 Part0 TYPE: 2105E20 SERIAL: 00A12028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk2 Part0 OPEN NORMAL 5 0 | || 1 Scsi Port7 Bus0/Disk7 Part0 OPEN NORMAL 9 0 | || | ||DEV#: 1 DEVICE NAME: Disk2 Part1 TYPE: 2105E20 SERIAL: 00A12028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk2 Part1 OPEN NORMAL 32 0 | || 1 Scsi Port7 Bus0/Disk7 Part1 OPEN NORMAL 32 0 | || | ||DEV#: 2 DEVICE NAME: Disk3 Part0 TYPE: 2105E20 SERIAL: 00B12028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk3 Part0 OPEN NORMAL 7 0 | || 1 Scsi Port7 Bus0/Disk8 Part0 OPEN NORMAL 9 0 | || | ||DEV#: 3 DEVICE NAME: Disk3 Part1 TYPE: 2105E20 SERIAL: 00B12028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk3 Part1 OPEN NORMAL 28 0 | || 1 Scsi Port7 Bus0/Disk8 Part1 OPEN NORMAL 36 0 | || | ||DEV#: 4 DEVICE NAME: Disk4 Part0 TYPE: 2105E20 SERIAL: 00D12028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk4 Part0 OPEN NORMAL 8 0 | || 1 Scsi Port7 Bus0/Disk9 Part0 OPEN NORMAL 6 0 | || | ||DEV#: 5 DEVICE NAME: Disk4 Part1 TYPE: 2105E20 SERIAL: 00D12028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk4 Part1 OPEN NORMAL 35 0 | || 1 Scsi Port7 Bus0/Disk9 Part1 OPEN NORMAL 29 0 | || | ||DEV#: 6 DEVICE NAME: Disk5 Part0 TYPE: 2105E20 SERIAL: 50812028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk5 Part0 OPEN NORMAL 6 0 | || 1 Scsi Port7 Bus0/Disk10 Part0 OPEN NORMAL 8 0 | || | ||DEV#: 7 DEVICE NAME: Disk5 Part1 TYPE: 2105E20 SERIAL: 50812028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk5 Part1 OPEN NORMAL 24 0 | || 1 Scsi Port7 Bus0/Disk10 Part1 OPEN NORMAL 40 0 | || | ||DEV#: 8 DEVICE NAME: Disk6 Part0 TYPE: 2105E20 SERIAL: 60012028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk6 Part0 OPEN NORMAL 8 0 | || 1 Scsi Port7 Bus0/Disk11 Part0 OPEN NORMAL 6 0 | || | ||DEV#: 9 DEVICE NAME: Disk6 Part1 TYPE: 2105E20 SERIAL: 60012028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk6 Part1 OPEN NORMAL 35 0 | || 1 Scsi Port7 Bus0/Disk11 Part1 OPEN NORMAL 29 0 | || | |+--------------------------------------------------------------------------------+
|The above example shows partition 0 (Part0) for each of the |device. This partition stores information about windows partition on |the drive. The operating system masks this partition from the user, but |it still exists. In general, you'll see one more partition from |the output of Datapath Query Device than what is being displayed from the Disk |Administrator application. |
|This section contains the procedures for adding new storage to existing |configuration in multipath environments.These procedures include: |
|Before adding any additional hardware, you should review the configuration |information for the adapters and devices currently on your Windows NT |server.
|You should verify that the number of adapters and the number of paths to |each ESS volume match the known configuration. Perform the following |steps to display information about the adapters and devices: |
|+--------------------------------------------------------------------------------+ || | ||Active Adapters :2 | || | ||Adpt# Adapter Name State Mode Select Errors Paths Active | || 0 Scsi Port6 Bus0 NORMAL ACTIVE 188 0 10 10 | || 1 Scsi Port7 Bus0 NORMAL ACTIVE 204 0 10 10 | || | ||Previous configuration with one additional path | || | || | || | |+--------------------------------------------------------------------------------+
|+--------------------------------------------------------------------------------+ || | ||Total Devices : 10 | || | ||DEV#: 0 DEVICE NAME: Disk2 Part0 TYPE: 2105E20 SERIAL: 00A12028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk2 Part0 OPEN NORMAL 5 0 | || 1 Scsi Port7 Bus0/Disk7 Part0 OPEN NORMAL 9 0 | || | ||DEV#: 1 DEVICE NAME: Disk2 Part1 TYPE: 2105E20 SERIAL: 00A12028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk2 Part1 OPEN NORMAL 32 0 | || 1 Scsi Port7 Bus0/Disk7 Part1 OPEN NORMAL 32 0 | || | ||DEV#: 2 DEVICE NAME: Disk3 Part0 TYPE: 2105E20 SERIAL: 00B12028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk3 Part0 OPEN NORMAL 7 0 | || 1 Scsi Port7 Bus0/Disk8 Part0 OPEN NORMAL 9 0 | || | ||DEV#: 3 DEVICE NAME: Disk3 Part1 TYPE: 2105E20 SERIAL: 00B12028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk3 Part1 OPEN NORMAL 28 0 | || 1 Scsi Port7 Bus0/Disk8 Part1 OPEN NORMAL 36 0 | || | ||DEV#: 4 DEVICE NAME: Disk4 Part0 TYPE: 2105E20 SERIAL: 00D12028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk4 Part0 OPEN NORMAL 8 0 | || 1 Scsi Port7 Bus0/Disk9 Part0 OPEN NORMAL 6 0 | || | ||DEV#: 5 DEVICE NAME: Disk4 Part1 TYPE: 2105E20 SERIAL: 00D12028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk4 Part1 OPEN NORMAL 35 0 | || 1 Scsi Port7 Bus0/Disk9 Part1 OPEN NORMAL 29 0 | || | ||DEV#: 6 DEVICE NAME: Disk5 Part0 TYPE: 2105E20 SERIAL: 50812028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk5 Part0 OPEN NORMAL 6 0 | || 1 Scsi Port7 Bus0/Disk10 Part0 OPEN NORMAL 8 0 | || | ||DEV#: 7 DEVICE NAME: Disk5 Part1 TYPE: 2105E20 SERIAL: 50812028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk5 Part1 OPEN NORMAL 24 0 | || 1 Scsi Port7 Bus0/Disk10 Part1 OPEN NORMAL 40 0 | || | ||DEV#: 8 DEVICE NAME: Disk6 Part0 TYPE: 2105E20 SERIAL: 60012028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk6 Part0 OPEN NORMAL 8 0 | || 1 Scsi Port7 Bus0/Disk11 Part0 OPEN NORMAL 6 0 | || | ||DEV#: 9 DEVICE NAME: Disk6 Part1 TYPE: 2105E20 SERIAL: 60012028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk6 Part1 OPEN NORMAL 35 0 | || 1 Scsi Port7 Bus0/Disk11 Part1 OPEN NORMAL 29 0 | || | |+--------------------------------------------------------------------------------+|
|Perform the following steps to install additional storage: |
|After adding new storage to existing configuration, you should |verify: |
|Perform the following steps to verify that the additional storage have been |installed correctly: |
|+--------------------------------------------------------------------------------+ || | ||Active Adapters :2 | || | ||Adpt# Adapter Name State Mode Select Errors Paths Active | || 0 Scsi Port6 Bus0 NORMAL ACTIVE 295 0 16 16 | || 1 Scsi Port7 Bus0 NORMAL ACTIVE 329 0 16 16 | || | || | |+--------------------------------------------------------------------------------+
|+--------------------------------------------------------------------------------+ || | ||Total Devices : 16 | || | ||DEV#: 0 DEVICE NAME: Disk2 Part0 TYPE: 2105E20 SERIAL: 00A12028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk2 Part0 OPEN NORMAL 9 0 | || 1 Scsi Port7 Bus0/Disk10 Part0 OPEN NORMAL 5 0 | || | ||DEV#: 1 DEVICE NAME: Disk2 Part1 TYPE: 2105E20 SERIAL: 00A12028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk2 Part1 OPEN NORMAL 26 0 | || 1 Scsi Port7 Bus0/Disk10 Part1 OPEN NORMAL 38 0 | || | ||DEV#: 2 DEVICE NAME: Disk3 Part0 TYPE: 2105E20 SERIAL: 00B12028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk3 Part0 OPEN NORMAL 9 0 | || 1 Scsi Port7 Bus0/Disk11 Part0 OPEN NORMAL 7 0 | || | ||DEV#: 3 DEVICE NAME: Disk3 Part1 TYPE: 2105E20 SERIAL: 00B12028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk3 Part1 OPEN NORMAL 34 0 | || 1 Scsi Port7 Bus0/Disk11 Part1 OPEN NORMAL 30 0 | || | ||DEV#: 4 DEVICE NAME: Disk4 Part0 TYPE: 2105E20 SERIAL: 31512028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk4 Part0 OPEN NORMAL 8 0 | || 1 Scsi Port7 Bus0/Disk12 Part0 OPEN NORMAL 6 0 | || | ||DEV#: 5 DEVICE NAME: Disk4 Part1 TYPE: 2105E20 SERIAL: 31512028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk4 Part1 OPEN NORMAL 35 0 | || 1 Scsi Port7 Bus0/Disk12 Part1 OPEN NORMAL 28 0 | || | ||DEV#: 6 DEVICE NAME: Disk5 Part0 TYPE: 2105E20 SERIAL: 00D12028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk5 Part0 OPEN NORMAL 5 0 | || 1 Scsi Port7 Bus0/Disk13 Part0 OPEN NORMAL 9 0 | || | ||DEV#: 7 DEVICE NAME: Disk5 Part1 TYPE: 2105E20 SERIAL: 00D12028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk5 Part1 OPEN NORMAL 28 0 | || 1 Scsi Port7 Bus0/Disk13 Part1 OPEN NORMAL 36 0 | || | ||DEV#: 8 DEVICE NAME: Disk6 Part0 TYPE: 2105E20 SERIAL: 40812028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk6 Part0 OPEN NORMAL 5 0 | || 1 Scsi Port7 Bus0/Disk14 Part0 OPEN NORMAL 9 0 | || | ||DEV#: 9 DEVICE NAME: Disk6 Part1 TYPE: 2105E20 SERIAL: 40812028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk6 Part1 OPEN NORMAL 25 0 | || 1 Scsi Port7 Bus0/Disk14 Part1 OPEN NORMAL 38 0 | || | ||DEV#: 10 DEVICE NAME: Disk7 Part0 TYPE: 2105E20 SERIAL: 50812028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk7 Part0 OPEN NORMAL 7 0 | || 1 Scsi Port7 Bus0/Disk15 Part0 OPEN NORMAL 7 0 | || | ||DEV#: 11 DEVICE NAME: Disk7 Part1 TYPE: 2105E20 SERIAL: 50812028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk7 Part1 OPEN NORMAL 34 0 | || 1 Scsi Port7 Bus0/Disk15 Part1 OPEN NORMAL 30 0 | || | ||DEV#: 12 DEVICE NAME: Disk8 Part0 TYPE: 2105E20 SERIAL: 60012028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk8 Part0 OPEN NORMAL 7 0 | || 1 Scsi Port7 Bus0/Disk16 Part0 OPEN NORMAL 7 0 | || | ||DEV#: 13 DEVICE NAME: Disk8 Part1 TYPE: 2105E20 SERIAL: 60012028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk8 Part1 OPEN NORMAL 29 0 | || 1 Scsi Port7 Bus0/Disk16 Part1 OPEN NORMAL 35 0 | || | ||DEV#: 14 DEVICE NAME: Disk9 Part0 TYPE: 2105E20 SERIAL: 00812028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk9 Part0 OPEN NORMAL 6 0 | || 1 Scsi Port7 Bus0/Disk17 Part0 OPEN NORMAL 8 0 | || | ||DEV#: 15 DEVICE NAME: Disk9 Part1 TYPE: 2105E20 SERIAL: 00812028 | ||===================================================================== | ||Path# Adapter/Hard Disk State Mode Select Errors | || 0 Scsi Port6 Bus0/Disk9 Part1 OPEN NORMAL 28 0 | || 1 Scsi Port7 Bus0/Disk17 Part1 OPEN NORMAL 36 0 | || | || | |+--------------------------------------------------------------------------------+
|The above example shows partition 0 (Part0) for each of the |device. This partition stores information about windows partition on |the drive. The operating system masks this partition from the user, but |it still exists. In general, you'll see one more partition from |the output of Datapath Query Device than what is being displayed from the Disk |Administrator application. |
Subsystem Device Driver 1.2.1 is required to support Windows NT clustering. Subsystem Device Driver 1.2.1 does not support I/O load-balancing in a Windows NT clustering environment.
There are subtle differences in the way that the Subsystem Device Driver handles path reclamation in a Windows NT clustering environment compared to a non-clustering environment. When the Windows NT server loses a path in a non-clustering environment, the path state changes from Open to Dead and the adapter state changes from Active to Degraded. The adapter and path state will not change until the path is made operational again. When the Windows NT server loses a path in a clustering environment, the path state changes from Open to Dead and the adapter state changes from Active to Degraded. However, after a period of time, the path state changes back to Open and the adapter state changes back to Normal, even if the path has not been made operational again.
The datapath set adapter # offline command operates differently in a clustering environment as compared to a non-clustering environment. In a clustering environment, the datapath set adapter offline command won't change the state of the path if the path is active or being reserved. If you issue the command the following message is displayed: to preserve access some paths left online
This chapter provides instructions to install and set up the Subsystem Device Driver on a Windows 2000 host system attached to an ESS.For updated and additional information not included in this chapter, see the README file on the compact disc or visit the Subsystem Device Driver Web site at: www.ibm.com/storage/support/techsup/swtechsup.nsf/support/sddupdates
Figure 5. Where the Subsystem Device Driver fits in the protocol stack
Notes:
The successful installation and operation of the Subsystem Device Driver involves the following hardware and software components:
|To successfully install the Subsystem Device Driver, your Windows |2000 host system should be an Intel-based system. Your host system |should have Windows 2000 Service Pack 2 installed. The host system can |be a uni-processor or a multi-processor system.
To successfully install the Subsystem Device Driver, ensure your ESS devices must be configured as IBM 2105xxx (where xxx is the ESS model number) on your Windows 2000 host system.
To use the Subsystem Device Driver SCSI support, ensure your host system meets the following requirements:
To use the Subsystem Device Driver fibre support, ensure your host system meets the following requirements:
The following environments are not supported by the Subsystem Device Driver:
Before you install the Subsystem Device Driver, configure your ESS for single-port or multiple-port access for each LUN. The Subsystem Device Driver requires a minimum of two independent paths that share the same logical unit to use the load balancing and failover features.
For information about configuring your ESS, see the IBM Enterprise Storage Server Introduction and Planning Guide.
Before you install and use the Subsystem Device Driver, you must configure your SCSI adapters. For SCSI adapters that attach boot devices, ensure that the BIOS for the adapter is enabled. For all other adapters that attach non-boot devices, ensure the BIOS for the adapter is disabled.
Unlike SCSI adapters, there are no special configuration requirements for fibre-channel adapters attached to Windows 2000 host systems.
The following section describes how to install the Subsystem Device Driver
Perform the following steps to install the Subsystem Device Driver filter and application programs on your system:
|To uninstall the Subsystem Device Driver on a Windows 2000 host system, |perform the following steps: |
|Attention: After uninstalling the previous version, you must |immediately install the new version of Subsystem Device Driver to |avoid any potential data loss (See Installing the Subsystem Device Driver on a Windows 2000 host system for instructions). |
|You can display the current version of the Subsystem Device Driver on a |Windows 2000 host system by viewing the sddpath.sys file |properties. To view the properties of sddpath.sys |file, perform the following steps: |
To activate the Subsystem Device Driver, you need to restart your Windows 2000 system after it is installed. In fact, a restart is required to activate multipath support whenever a new file system or partition is added.
Attention: Ensure that the Subsystem Device Driver is installed before you add additional paths to a device. Otherwise, the Windows 2000 server's ability to access existing data on that device could be lost.
Before adding any additional hardware, you should review the configuration information for the adapters and devices currently on your Windows 2000 server. Perform the following steps to display information about the adapters and devices:
+--------------------------------------------------------------------------------+ |Active Adapters :1 | | | |Adpt# Adapter Name State Mode Select Errors Paths Active | | 0 Scsi Port1 Bus0 NORMAL ACTIVE 4057 0 8 8 | +--------------------------------------------------------------------------------+
+--------------------------------------------------------------------------------+ |Total Devices : 8 | | | |DEV#: 0 DEVICE NAME: Disk7 Part7 TYPE: 2105E20 SERIAL: 01312028 | |===================================================================== | |Path# Adapter/Hard Disk State Mode Select Errors | | 0 Scsi Port1 Bus0/Disk7 Part0 OPEN NORMAL 1045 0 | | | |DEV#: 1 DEVICE NAME: Disk6 Part6 TYPE: 2105E20 SERIAL: 01212028 | |===================================================================== | |Path# Adapter/Hard Disk State Mode Select Errors | | 0 Scsi Port1 Bus0/Disk6 Part0 OPEN NORMAL 391 0 | | | |DEV#: 2 DEVICE NAME: Disk5 Part5 TYPE: 2105E20 SERIAL: 01112028 | |===================================================================== | |Path# Adapter/Hard Disk State Mode Select Errors | | 0 Scsi Port1 Bus0/Disk5 Part0 OPEN NORMAL 1121 0 | | | |DEV#: 3 DEVICE NAME: Disk4 Part4 TYPE: 2105E20 SERIAL: 01012028 | |===================================================================== | |Path# Adapter/Hard Disk State Mode Select Errors | | 0 Scsi Port1 Bus0/Disk4 Part0 OPEN NORMAL 332 0 | | | |DEV#: 4 DEVICE NAME: Disk3 Part3 TYPE: 2105E20 SERIAL: 00F12028 | |===================================================================== | |Path# Adapter/Hard Disk State Mode Select Errors | | 0 Scsi Port1 Bus0/Disk3 Part0 OPEN NORMAL 375 0 | | | |DEV#: 5 DEVICE NAME: Disk2 Part2 TYPE: 2105E20 SERIAL: 31412028 | |===================================================================== | |Path# Adapter/Hard Disk State Mode Select Errors | | 0 Scsi Port1 Bus0/Disk2 Part0 OPEN NORMAL 258 0 | | | |DEV#: 6 DEVICE NAME: Disk1 Part1 TYPE: 2105E20 SERIAL: 31312028 | |===================================================================== | |Path# Adapter/Hard Disk State Mode Select Errors | | 0 Scsi Port1 Bus0/Disk1 Part0 OPEN NORMAL 267 0 | | | |DEV#: 7 DEVICE NAME: Disk0 Part0 TYPE: 2105E20 SERIAL: 31212028 | |===================================================================== | |Path# Adapter/Hard Disk State Mode Select Errors | | 0 Scsi Port1 Bus0/Disk0 Part0 OPEN NORMAL 268 0 | | | +--------------------------------------------------------------------------------+
Perform the following steps to activate additional paths to a vpath device:
After installing additional paths to Subsystem Device Driver devices, you should verify that the additional paths have been installed correctly.
Perform the following steps to verify that the additional paths have been installed correctly:
+--------------------------------------------------------------------------------+ |Active Adapters :2 | | | |Adpt# Adapter Name State Mode Select Errors Paths Active | | 0 Scsi Port1 Bus0 NORMAL ACTIVE 1325 0 8 8 | | 1 Scsi Port2 Bus0 NORMAL ACTIVE 1312 0 8 8 | +--------------------------------------------------------------------------------+
+--------------------------------------------------------------------------------+ |Total Devices : 8 | | | |DEV#: 0 DEVICE NAME: Disk7 Part7 TYPE: 2105E20 SERIAL: 01312028 | |========================================================================= | |Path# Adapter/Hard Disk State Mode Select Errors | | 0 Scsi Port1 Bus0/Disk7 Part0 OPEN NORMAL 190 0 | | 1 Scsi Port2 Bus0/Disk15 Part0 OPEN NORMAL 179 0 | | | |DEV#: 1 DEVICE NAME: Disk6 Part6 TYPE: 2105E20 SERIAL: 01212028 | |========================================================================= | |Path# Adapter/Hard Disk State Mode Select Errors | | 0 Scsi Port1 Bus0/Disk6 Part0 OPEN NORMAL 179 0 | | 1 Scsi Port2 Bus0/Disk14 Part0 OPEN NORMAL 184 0 | | | |DEV#: 2 DEVICE NAME: Disk5 Part5 TYPE: 2105E20 SERIAL: 01112028 | |========================================================================= | |Path# Adapter/Hard Disk State Mode Select Errors | | 0 Scsi Port1 Bus0/Disk5 Part0 OPEN NORMAL 194 0 | | 1 Scsi Port2 Bus0/Disk13 Part0 OPEN NORMAL 179 0 | | | |DEV#: 3 DEVICE NAME: Disk4 Part4 TYPE: 2105E20 SERIAL: 01012028 | |========================================================================= | |Path# Adapter/Hard Disk State Mode Select Errors | | 0 Scsi Port1 Bus0/Disk4 Part0 OPEN NORMAL 187 0 | | 1 Scsi Port2 Bus0/Disk12 Part0 OPEN NORMAL 173 0 | | | |DEV#: 4 DEVICE NAME: Disk3 Part3 TYPE: 2105E20 SERIAL: 00F12028 | |========================================================================= | |Path# Adapter/Hard Disk State Mode Select Errors | | 0 Scsi Port1 Bus0/Disk3 Part0 OPEN NORMAL 215 0 | | 1 Scsi Port2 Bus0/Disk11 Part0 OPEN NORMAL 216 0 | | | |DEV#: 5 DEVICE NAME: Disk2 Part2 TYPE: 2105E20 SERIAL: 31412028 | |========================================================================= | |Path# Adapter/Hard Disk State Mode Select Errors | | 0 Scsi Port1 Bus0/Disk2 Part0 OPEN NORMAL 115 0 | | 1 Scsi Port2 Bus0/Disk10 Part0 OPEN NORMAL 130 0 | | | |DEV#: 6 DEVICE NAME: Disk1 Part1 TYPE: 2105E20 SERIAL: 31312028 | |======================================================================= | |Path# Adapter/Hard Disk State Mode Select Errors | | 0 Scsi Port1 Bus0/Disk1 Part0 OPEN NORMAL 122 0 | | 1 Scsi Port2 Bus0/Disk9 Part0 OPEN NORMAL 123 0 | | | |DEV#: 7 DEVICE NAME: Disk0 Part0 TYPE: 2105E20 SERIAL: 31212028 | |========================================================================= | |Path# Adapter/Hard Disk State Mode Select Errors | | 0 Scsi Port1 Bus0/Disk0 Part0 OPEN NORMAL 123 0 | | 1 Scsi Port2 Bus0/Disk8 Part0 OPEN NORMAL 128 0 | +--------------------------------------------------------------------------------+
This chapter provides instructions to install and set up the Subsystem Device Driver on an HP host system attached to an ESS. For updated and additional information not included in this manual, please see the README file on the compact disc or go to the Subsystem Device Driver Web site at: www.ibm.com/storage/support/techsup/swtechsup.nsf/support/sddupdates
Notes:
The following section briefly describes the Subsystem Device Driver
failover system and the device driver.
|The Subsystem Device Driver supports 32-bit and 64-bit applications on
|HP-UX 11.0.
|Attention: HP patches (as appropriate for a 32-bit or 64-bit
|application) must be installed on your host system to ensure that the
|Subsystem Device Driver operates successfully. See Table 11.
|Support for 32-bit and 64-bit applications on HP-UX 11.0
|
|
The Subsystem Device Driver failover system is designed to provide recovery upon failure of a data path. If a data path fails, the failover system selects an alternate data path and minimizes any disruptions in operation. This failover process consists of:
The Subsystem Device Driver dynamically selects an alternate I/O data path when a software or hardware problem is detected.
The Subsystem Device Driver resides above the HP SCSI disk driver (sdisk) in the protocol stack (see Figure 6).
Figure 6. Where the Subsystem Device Driver fits in the protocol stack
Subsystem Device Driver devices behave exactly like sdisk devices. Any operation on an sdisk device can be performed on the Subsystem Device Driver device, including commands such as mount, open, close, umount, dd, newfs, or fsck. For example, with the Subsystem Device Driver you use the mount /dev/dsk/vpath0 /mnt1 command instead of the HP-UX mount /dev/dsk/clt2d0 /mnt1 command.
The Subsystem Device Driver acts as a pass-through agent. I/O operations sent to the Subsystem Device Driver are passed to an sdisk driver after path selection. When an active path experiences a failure (such as a cable or controller failure), the Subsystem Device Driver dynamically switches to another path. The device driver dynamically balances the load, based on the workload of the adapter.
The Subsystem Device Driver also supports one SCSI adapter on the host system. With single-path access, concurrent download of licensed internal code is supported. However, the load balancing and failover features are not available.
To be able to install the Subsystem Device Driver on your HP host system, you must meet the following minimum hardware and software requirements:
To install the Subsystem Device Driver and use the input-output load balancing and failover features, you need a minimum of two SCSI or fibre-channel adapters.
Notes:
Before you install the Subsystem Device Driver, configure your ESS for single-port or multiple-port access for each LUN. The Subsystem Device Driver requires that you provide a minimum of two independent paths that share the same logical unit to use the load balancing and failover features.
For information about configuring your ESS, see IBM Enterprise Storage Server Introduction and Planning Guide, GC26-7294.
Before you install Subsystem Device Driver on your HP host, you need to understand what kind of software runs on your host. The way you install Subsystem Device Driver depends on the kind of software you have running. There are two types of special device files that are supported:
There are three possible scenarios for installing Subsystem Device Driver. The scenario you choose depends on the kind of software you have installed:
The following table further describes the various installation scenarios and how you should proceed.
Table 10. Subsystem Device Driver installation scenarios
| Installation Scenario | Description | How To Proceed |
| Scenario 1 |
| Go to: |
| Scenario 2 |
| Go to: |
| Scenario 3 | Subsystem Device Driver installed | Go to Upgrading the Subsystem Device Driver |
|For the Subsystem Device Driver to operate properly on HP-UX
|11.0, ensure that the following patches are installed on your operation
|system:
|
|
|Table 11. HP patches necessary for proper operation of Subsystem Device Driver
|
Application mode:
Install HP Patch:
Patch Description:
32-bit
PHKL_20674
Fix VxFS unmount hang & NMF, sync panics
32-bit
PHKL_20915
Trap-related panics/hangs
32-bit
PHKL_21834
Fibre channel Mass Storage Driver Patch
32-bit
PHKL_22759
SCSI IO Subsystem Cumulative patch
32-bit
PHKL_23001
Signal, threads, spinlock, scheduler, IDS, q3p
32-bit
PHKL_23406
Probe, sysproc, shmem, thread cumulative patch
32-bit or 64-bit
PHKL_21392
VxFS performance, hang, icache, DPFs
32-bit or 64-bit
PHKL_21624
Boot, JFS, PA8600, 3Gdata, NFS, IDS, PM, VM, async
32-bit or 64-bit
PHKL_21989
SCSI IO Subsystem Cumulative patch
64-bit
PHKL_21381
Fibre Channel Mass Storage driver
You need to complete the following procedure if you are installing Subsystem Device Driver for the first time on your HP host:
|mount /dev/dsk/c0t2d0 /cdrom
|or
|mount /dev/dsk/c0t2d0 /your_installation_directory
> sam
|For 32-bit mode applications, use:
|/cdrom/hp32bit/IBMdpo.depot
|or
|/your_installation_directory/hp32bit/IBMdpo.depot
|For 64-bit mode applications, use:
|/cdrom/hp64bit/IBMdpo.depot
|or
|/your_installation_directory/hp32bit/IBMdpo.depot
|
|Figure 7. IBMdpo Driver 32-bit
|+--------------------------------------------------------------------------------+ ||Name Revision Information Size(Kb) | ||IBMdpo_tag -> B.11.00.01 IBMdpo Driver 32-bit nnnn | |+--------------------------------------------------------------------------------+
|Figure 8. IBMdpo Driver 64-bit
|+--------------------------------------------------------------------------------+ ||Name Revision Information Size(Kb) | ||IBMdpo_tag -> B.11.00.01 IBMdpo Driver 64-bit nnnn | |+--------------------------------------------------------------------------------+|
|+--------------------------------------------------------------------------------+ ||Press 'Product Summary' and/or 'Logfile' for more target information. | ||Target : XXXXX | ||Status : Building kernel | ||Percent Complete : 17% | ||Kbytes Installed : 276 of 1393 | ||Time Left (minutes) : 1 | ||Product Summary Logfile | ||Done Help | |+--------------------------------------------------------------------------------+|While the installation process is going on, the Done |option is not available for you to select. Once the installation of the |software has completed, the option is available for you to select. |
+--------------------------------------------------------------------------------+ |* A reboot of this system is being invoked. Please wait. | | | |*** FINAL System shutdown message (XXXXX) *** | |System going down IMMEDIATELY | +--------------------------------------------------------------------------------+
After Subsystem Device Driver is installed, the device driver resides above
the HP SCSI disk driver (sdisk) in the protocol stack. In other words,
Subsystem Device Driver now talks to the HP-UX device layer. The
Subsystem Device Driver software installation procedure installs a number of
Subsystem Device Driver components and updates some system files. Those
components and files are listed in the following tables:
Table 12. Subsystem Device Driver components installed
| File | Location | Description |
| libvpath.a | /usr/conf/lib | Subsystem Device Driver device driver |
| vpath | /usr/conf/master.d | Subsystem Device Driver configuration file |
| Executables | /opt/IBMdpo/bin | Configuration and status tools |
| README.sd | /opt/IBMdpo | README file |
| defvpath | /sbin | Subsystem Device Driver configuration file used during startup |
Table 13. System files updated
| File | Location | Description |
| system | /stand/build | Forces the loading of the Subsystem Device Driver device driver |
| lvmrc | /etc | Causes defvpath to run at boot time |
Table 14. Subsystem Device Driver commands and their descriptions
| Command | Description |
|---|---|
| cfgvpath | Configures vpath devices |
| defvpath | Second part of cfgvpath configuration during boot time |
| showvpath | Lists the configuration mapping between Subsystem Device Driver devices and underlying disks |
| datapath | Subsystem Device Driver driver console command tool |
If you are not using a DBMS or an application package that talks directly to the sdisk interface, then the installation procedure is nearly complete. However, you still need to customize HP-UX so that standard UNIX applications can use Subsystem Device Driver. Go to section Standard UNIX applications. If you have a DBMS or an application package installed that talks directly to the sdisk interface, such as Oracle, go to Using applications with Subsystem Device Driver and read the information specific to the application you will be using.
Upgrading the Subsystem Device Driver consists of uninstalling and reinstalling the IBMdpo package. If you are upgrading Subsystem Device Driver, go to Uninstalling Subsystem Device Driver and then go to Installing the Subsystem Device Driver.
If your system already has a software application or an DBMS installed that communicates directly with the HP-UX disk device drivers, you need to insert the new Subsystem Device Driver device layer between the software application and the HP-UX disk device layer. You also need to customize the software application in order to have it communicate with the Subsystem Device Driver devices instead of the HP-UX devices.
In addition, many software applications and DBMSs need to control certain device attributes such as ownership and permissions. Therefore, you must ensure that the new Subsystem Device Driver devices that these software applications or DBMSs access in the future have the same attributes as the HP-UX sdisk devices that they replace. You need to customize the application or DBMS to accomplish this.
This section contains the procedures for customizing the following software applications and DBMS for use with Subsystem Device Driver:
If you have not already done so, install Subsystem Device Driver using the procedure in Installing the Subsystem Device Driver. When this is done, the Subsystem Device Driver resides above the HP SCSI disk driver (sdisk) in the protocol stack. In other words, Subsystem Device Driver now talks to the HP-UX device layer. To use standard UNIX applications with Subsystem Device Driver, you must make some changes to your logical volumes. You must either convert your existing logical volumes or create new ones.
Standard UNIX applications such as newfs, fsck, mkfs, and mount, that normally take a disk device or raw disk device as a parameter, also accept the Subsystem Device Driver device as a parameter. Similarly, entries in files such as vfstab and dfstab (in the format of cntndnsn) can be replaced by entries for the corresponding Subsystem Device Driver devices' vpathNs. Make sure that the devices that are replaced are replaced with the corresponding Subsystem Device Driver device. Running the showvpath command lists all Subsystem Device Driver devices and their underlying disks.
In order to use the Subsystem Device Driver driver for an existing logical volume, it is necessary to remove the existing logical volume and volume group and recreate it using the Subsystem Device Driver device.
Attention: Do not use the Subsystem Device Driver for critical file systems needed at boot time, such as /(root), /stand, /usr, /tmp or /var. Doing so may render your system unusable if Subsystem Device Driver is ever uninstalled (for example, as part of an upgrade).
The task of converting an existing logical volume to use Subsystem Device Driver can be broken down into the following subtasks:
As an example, suppose you have a logical volume called lvol1 under a volume group vgibm, which is currently using the disk directly, (for example, through path /dev path /dev/dsk/c3t4d0). You would like to convert logical volume lvol1 to use Subsystem Device Driver. In order to recreate the logical volume, you first need to determine the size of the logical volume.
Use the lvdisplay command to determine this:
# lvdisplay | grep LV Size
A message is displayed:
+--------------------------------------------------------------------------------+ |LV Size (Mbytes) 100 | +--------------------------------------------------------------------------------+
In this case, the logical volume size is 100 megabytes. Next, remove the logical volume from the system.
Before the logical volume is removed, it must be unmounted. Here is an example of using the umount command to unmount logical volume lvol1:
# umount /dev/vgibm/lvol1
Next, remove the logical volume. You can use the following command to remove logical volume lvol1:
# lvremove /dev/vgibm/lvol1
A message is displayed:
+--------------------------------------------------------------------------------+ |The logical volume "/dev/vgibm/lvol1" is not empty; | |do you really want to delete the logical volume (y/n) | +--------------------------------------------------------------------------------+
Type Y and press Enter. A message is displayed that is similar to the following:
+--------------------------------------------------------------------------------+ |Logical volume "/dev/vgibm/lvol1" has been successfully removed. | |Volume Group configuration for /dev/vgibm has been saved in | |/etc/lvmconf/vgibm.conf | +--------------------------------------------------------------------------------+
When prompted to delete the logical volume, type y.
Next, remove the volume group.
You can use the following command to remove the volume group vgibm:
# vgremove /dev/vgibm
You see a message similar to this:
+--------------------------------------------------------------------------------+ |Volume group "/dev/vgibm" has been successfully removed. | +--------------------------------------------------------------------------------+
Now recreate the logical volume.
Recreating the logical volume consists of a number of smaller steps:
Use the following command to recreate the physical volume:
# pvcreate /dev/rdsk/vpath0
You see a message similar to this:
+--------------------------------------------------------------------------------+ |Physical volume "/dev/rdsk/vpath0" has been successfully created. | +--------------------------------------------------------------------------------+
This assumes that the Subsystem Device Driver device associated with the underlying disk is vpath0. Verify this with the showvpath command:
# /opt/IBMdpo/bin/showvpath
A message is displayed:
+--------------------------------------------------------------------------------+ |vpath0: | | /dev/dsk/c3t4d0 | +--------------------------------------------------------------------------------+
Next, recreate the volume group.
Use the following command to recreate the volume group:
# vgcreate /dev/vgibm /dev/dsk/vpath0
You see a message that says:
+--------------------------------------------------------------------------------+ |Increased the number of physical extents per physical volume to 2187. | |Volume group "/dev/vgibm" has been successfully created. | |Volume Group configuration for /dev/vgibm has been saved in | |/etc/lvmconf/vgibm.conf | +--------------------------------------------------------------------------------+
Now recreate the logical volume.
Attention: The recreated logical volume should be the same size as the original volume; otherwise, the recreated volume cannot store the data that was on the original.
Use the following command used to recreate the logical volume:
# lvcreate -L 100 -n lvol1 vgibm
You see a message that says:
+--------------------------------------------------------------------------------+ |Logical volume "/dev/vgibm/lvol1" has been successfully created with | |character device "/dev/vgibm/rlvol1". | |Logical volume "/dev/vgibm/lvol1" has been successfully extended. | |Volume Group configuration for /dev/vgibm has been saved in | |/etc/lvmconf/vgibm.conf | +--------------------------------------------------------------------------------+
Note that the -L 100 parameter comes from the size of the original logical volume, determined by using the lvdisplay command. In this example, the original logical volume was 100 MB in size.
Attention: The timeout values for the logical volume manager must be set correctly for the Subsystem Device Driver to operate properly. This is particularly true if you are going to be using concurrent microcode download.
If you are going to be using concurrent microcode download with single-path SCSI, perform the following steps to set the correct timeout value for the logical volume manager:
If you are going to be using concurrent microcode download with multi-path SCSI, perform the following steps to set the proper timeout value for the logical volume manager:
Attention: In some cases it may be necessary to use standard HP recovery procedures to fix a volume group that has become damaged or corrupted. For information on using recovery procedures, such as, vgscan, vgextend, vpchange, or vgreduce, see the HP-UX Reference Volume 2 at the Web site: docs.hp.com.
The task of creating a new logical volume to use Subsystem Device Driver can be broken down into the following subtasks:
In order to create a new logical volume that uses the Subsystem Device Driver, you first need to determine the major number of the logical volume device.
Use the lsdev command to determine this:
# lsdev | grep lv
A message is displayed:
+--------------------------------------------------------------------------------+ |64 64 lv lvm | +--------------------------------------------------------------------------------+
The first number is the major number of the character device, which is what you want to use. Next, create a device node for the logical volume device.
Creating a device node actually consists of:
Use the following command to create a directory in /dev for the volume group:
# mkdir /dev/vgibm
In this example, vgibm is the name of the directory.
Next, change to the directory that you just created
Use the following command to change to the /dev directory:
# cd /dev/vgibm
Next, create a device node for the logical volume device.
If you do not have any other logical volume devices, you can use a minor number of 0x010000. In this example, assume that you have no other logical volume devices. Use the following command to create a device node:
# mknod group c 64 0x010000
Now create a physical volume.
Use the following command to create a physical volume:
# pvcreate /dev/rdsk/vpath0
Now create the volume group
Use the following command to create a volume group:
# vgcreate /dev/vgibm /dev/dsk/vpath0
Now create the logical volume.
Use the following command to create logical volume lvol1 :
# lvcreate -L 100 -n lvol1 vgibm
The -L 100 makes a 100 MB volume group; you can make it larger if you want to. Now you are ready to create a file system on the volume group.
Use the following command to create a file system on the volume group:
# newfs -F hfs /dev/vgibm/rlvol1
Finally, mount the logical volume (assuming that you have a mount point called /mnt).
Use the following command to mount the logical volume lvol1:
# mount /dev/vgibm/lvol1 /mnt
Attention: In some cases it may be necessary to use standard HP recovery procedures to fix a volume group that has become damaged or corrupted. For information on using recovery procedures, such as, vgscan, vgextend, vpchange, or vgreduce, see the HP-UX Reference Volume 2 at the Web site: docs.hp.com.
The procedures in this section show how to install Subsystem Device Driver for use with an exported file system (Network File System file server).
Follow the instructions in this section if you are installing exported file systems on Subsystem Device Driver devices for the first time:
# newfs /dev/rdsk/vpathN
In this example, N is the Subsystem Device Driver device instance of the selected volume. Create mount points for the new file systems.
Follow the instructions in this section if you have Network File System file server already configured for exported file systems that reside on a multi-port subsystem, and if you want to use Subsystem Device Driver partitions instead of sdisk partitions to access them.
If there is a problem with any exported file system after completing step 6, restore the original /etc/fstab file and reboot to restore Network File System service. Then review your steps and try again.
Notes:
You can set up your Oracle database in one of two ways. You can set it up to use a file system or raw partitions. The procedure for installing your database differs depending on the choice you make.
Notes:
In the following procedure you will be replacing the raw devices with the Subsystem Device Driver devices.
Your installation procedure for a new Subsystem Device Driver install will differ depending on whether you are using a file system or raw partitions for your Oracle database.
Follow this procedure if you are installing Subsystem Device Driver for the first time on a system with an Oracle database that uses a file system:
If you would originally have used:
mount /dev/dsk/c1t3d2 /oracle/mp1
You now use:
mount /dev/dsk/vpath2 /oracle/mp1
(assuming that you had found vpath2 to be the Subsystem Device Driver identifier)
Follow the instructions in the Oracle Installation Guide for setting ownership and permissions.
Follow this procedure if you have Oracle8 already installed and want to reconfigure it to use Subsystem Device Driver partitions instead of sdisk partitions (for example, partitions accessed through /dev/rdsk/cntndn files).
All Oracle8 control, log, and data files are accessed either directly from mounted file systems, or using links from the oradata subdirectory of each Oracle mount point set up on the server. Therefore, the process of converting an Oracle installation from sdisk to Subsystem Device Driver has two parts:
Following are the conversion steps:
select * from sys.dba_data_files;
Determine the underlying device that each data file resides on, either by looking up mounted file systems in /etc/fstab, or by extracting raw device link names directly from the select command output.
| Oracle Device Link | File Attributes | Subsystem Device Driver Device Link | ||
| Owner | Group | Permissions |
| |
| /dev/rdsk/c1tld0 | oracle | dba | 644 | /dev/rdsk/vpath4 |
/opt/IBMdpo/bin/showvpath
Complete the following procedure to uninstall the Subsystem Device Driver:
> sam
+--------------------------------------------------------------------------------+ |Target : XXXXX | |Status : Executing unconfigure | |Percent Complete : 17% | |Kbytes Removed : 340 of 2000 | |Time Left (minutes) : 5 | |Removing Software : IBMdpo_tag,........... | +--------------------------------------------------------------------------------+While the uninstall process is going on, the Done option is not available for you to select. Once the uninstall is complete, the option is available for you to select.
+--------------------------------------------------------------------------------+ |* A reboot of this system is being invoked. Please wait. | | | |*** FINAL System shutdown message (XXXXX) *** | |System going down IMMEDIATELY | +--------------------------------------------------------------------------------+
The uninstall of the Subsystem Device Driver involved the following actions:
When adding or removing multi-port SCSI devices from your system, you must reconfigure Subsystem Device Driver to recognize the new devices. Perform the following steps to reconfigure Subsystem Device Driver:
shutdown -r 0
/opt/IBMdpo/bin/cfgvpath -c
shutdown -r 0
Notes:
This chapter provides instructions to install and set up the Subsystem Device Driver on an host system attached to an ESS.
The Subsystem Device Driver failover system is designed to provide recovery upon failure of a data path. If this situation occurs, then the failover system selects an alternate data path, while minimizing any disruptions in operation. This failover process consists of:
The Subsystem Device Driver dynamically selects an alternate I/O data path when a software or hardware problem is detected. For the failover system to work, the device must be configured for multi-path access.
Notes:
The Subsystem Device Driver resides above the Sun SCSI disk driver (sd) in the protocol stack. There can be a maximum of eight sd devices underneath each Subsystem Device Driver device in the protocol stack. Each sd device represents a different path to the physical device. There can be up to eight sd devices that represent up to eight different paths to the physical device.
Figure 9. Where the Subsystem Device Driver fits in the protocol stack
Subsystem Device Driver devices behave exactly like sd devices. Any operation on an sd device can be performed on the Subsystem Device Driver device, including commands such as mount, open, close, umount, dd, newfs, or fsck. For example, with Subsystem Device Driver you enter mount /dev/dsk/vpath0c /mnt1 instead of the Solaris mount /dev/dsk/c1t2d0s2 /mnt1 command.
The Subsystem Device Driver acts as a pass-through agent. I/Os sent to the device driver are passed to an sdisk driver after path selection. When an active path experiences a failure (such as a cable or controller failure), the device driver dynamically switches to another path. The device driver dynamically balances the load, based on the workload of the adapter.
The Subsystem Device Driver also supports one SCSI adapter on the host system. With single-path access, concurrent download of licensed internal code is supported. However, the load balancing and failover features are not available.
You must meet the following minimum hardware and software requirements to install the Subsystem Device Driver on your host system:
To install the Subsystem Device Driver and use the input-output load balancing and failover features, you need a minimum of two SCSI or fibre-channel adapters.
Notes:
Before you install the Subsystem Device Driver, configure your ESS for single-port or multiple-port access for each LUN. The Subsystem Device Driver requires a minimum of two independent paths that share the same logical unit to use the load balancing and failover features.
For information about configuring your ESS, see IBM Enterprise Storage Server Introduction and Planning Guide, GC26-7294.
Before you install Subsystem Device Driver on your Sun host, you need to understand what kind of software is running on it. The way you install Subsystem Device Driver depends on the kind of software you are running. Basically, there are three types of software that talk directly to raw or block disk device interfaces such as sd and Subsystem Device Driver:
There are three possible scenarios for installing Subsystem Device Driver. The scenario you choose depends on the kind of software you have installed:
The following table further describes the various installation scenarios
and how you should proceed.
Table 15. Subsystem Device Driver installation scenarios
| Installation Scenario | Description | How To Proceed |
| Scenario 1 |
| Go to: |
| Scenario 2 |
| Go to: |
| Scenario 3 | Subsystem Device Driver installed | Go to: Upgrading the Subsystem Device Driver |
The following table lists the install package file names that come with the
Subsystem Device Driver.
Table 16. Subsystem Device Driver package file names
| Package file names | Description |
|---|---|
| sun32bit/IBMdpo | Solaris 2.6 |
| sun64bit/IBMdpo | Solaris 7 |
| sun64bit/IBMdpo | Solaris 8 |
For the Subsystem Device Driver to operate properly, ensure that the
following Solaris patches are installed on your operating system:
Table 17. Solaris patches necessary for proper operation of Subsystem Device Driver
|
| Solaris 2.6 | Solaris 7 |
|---|---|---|
| glm | 105580-15 | 106925-04 |
| isp | 105600-19 | 106924-06 |
| sd & ssd | 105356-16 | 107458-10 |
Attention: Analyze and study your operating and application environment to ensure there are no conflicts with these patches prior to their installation.
Go to the following Web site for the latest information on Solaris patches sunsolve.Sun.COM
You need to complete the following procedure if you are installing Subsystem Device Driver for the first time on your Sun host.
# cd /cdrom/cdrom0/sun32bit or # cd /cdrom/cdrom0/sun64bit
pkgadd -d /cdrom/cdrom0/sun32bit IBMdpo or pkgadd -d /cdrom/cdrom0/sun64bit IBMdpo
+--------------------------------------------------------------------------------+ |Processing package instance <IBMdpo> from <var/spool/pkg> | | | | | |IBM DPO driver | |(sparc) 1 | |## Processing package information. | |## Processing system information. | |## Verifying disk space requirements. | |## Checking for conflicts with packages already installed. | |## Checking for setuid/setgid programs. | | | |This package contains scripts which will be executed with super-user | |permission during the process of installing this package. | | | |Do you want to continue with the installation of <IBMdpo> [y,n,?] | +--------------------------------------------------------------------------------+
+--------------------------------------------------------------------------------+ |Installing IBM DPO driver as <IBMdpo> | | | |## Installing part 1 of 1. | |/etc/defvpath | |/etc/rc2.d/S00vpath-config | |/etc/rcS.d/S20vpath-config | |/kernel/drv/vpathdd | |/kernel/drv/vpathdd.conf | |/opt/IBMdpo/cfgvpath | |/opt/IBMdpo/datapath | |/opt/IBMdpo/devlink.vpath.tab | |/opt/IBMdpo/etc.system | |/opt/IBMdpo/pathtest | |/opt/IBMdpo/showvpath | |/usr/sbin/vpathmkdev | |[ verifying class <none> ] | |## Executing postinstall script. | | | |DPO: Configuring 24 devices (3 disks * 8 slices) | | | |Installation of <IBMdpo> was successful. | | | |The following packages are available: | |1 IBMcli ibm2105cli | | (sparc) 1.1.0.0 | |2 IBMdpo IBM DPO driver Version: May-10-2000 16:51 | | (sparc) 1 | |Select package(s) you wish to process (or 'all' to process | |all packages). (default: all) [?,??,q]: | +--------------------------------------------------------------------------------+Type q and press Enter to proceed.
+--------------------------------------------------------------------------------+ |*** IMPORTANT NOTICE *** | |This machine must now be rebooted in order to ensure | |sane operation. Execute | | shutdown -y -i6 -g0 | |and wait for the "Console Login:" prompt. | | | |DPO is now installed. Proceed to Post-Installation. | +--------------------------------------------------------------------------------+
After the installation is complete, manually unmount the compact disc. Run the umount /cdrom command from the root directory. Go to the CD-ROM drive and press the Eject button.
After Subsystem Device Driver is installed, your system must be rebooted to ensure proper operation. Type the command:
# shutdown -i6 -g0 -y
After Subsystem Device Driver is installed, the device driver resides above
the Sun SCSI disk driver (sd) in the protocol stack. In other words,
Subsystem Device Driver now talks to the Solaris device layer. The
Subsystem Device Driver software installation procedure installs a number of
Subsystem Device Driver components and updates some system files. Those
components and files are listed in the following tables:
Table 18. System files updated
| File | Location | Description |
| /etc/system | /etc | Forces the loading of the Subsystem Device Driver |
| /etc/devlink.tab | /etc | Tells the system how to name Subsystem Device Driver devices in /dev |
Table 19. Subsystem Device Driver components installed
| File | Location | Description |
| vpathdd | /kernel/drv | Device driver |
| vpathdd.conf | /kernel/drv | Subsystem Device Driver config file |
| Executables | /opt/IBMdpo/bin | Configuration and status tools |
| S20vpath-config | /etc/rcS.d | Boot initialization script* |
Table 20. Subsystem Device Driver commands and their descriptions
| Command | Description |
|---|---|
| cfgvpath | Configures vpath devices |
| showvpath | Lists all Subsystem Device Driverdevices and their underlying disks |
| vpathmkdev | Create Subsystem Device Driver devices for /dev/dsk entries |
| datapath | Subsystem Device Driver driver console command tool |
If you are not using a volume manager, software application, or DBMS that talks directly to the sd interface, then the installation procedure is nearly complete. If you have a volume manager, software application, or DBMS installed that talks directly to the sd interface, such as Oracle, go to Using applications with Subsystem Device Driver and read the information specific to the application you will be using.
Upgrading the Subsystem Device Driver consists of uninstalling and reinstalling the IBMdpo package. If you are upgrading Subsystem Device Driver, go to Uninstalling Subsystem Device Driver and then go to Installing the Subsystem Device Driver.
If your system already has a volume manager, software application, or DBMS installed that communicates directly with the Solaris disk device drivers, you need to insert the new Subsystem Device Driver device layer between the program and the Solaris disk device layer. You also need to customize the volume manager, software application, or DBMS in order to have it communicate with the Subsystem Device Driver devices instead of the Solaris devices.
In addition, many software applications and DBMSs need to control certain device attributes such as ownership and permissions. Therefore, you must ensure that the new Subsystem Device Driver devices that these software applications or DBMSs access in the future have the same attributes as the Solaris sd devices that they replace. You need to customize the software application or DBMS to accomplish this.
This section describes how to use the following applications with Subsystem Device Driver:
If you have not already done so, install Subsystem Device Driver using the procedure in section Installing the Subsystem Device Driver. When this is done, the device driver resides above the Solaris SCSI disk driver (sd) in the protocol stack. In other words, the Subsystem Device Driver now talks to the Solaris device layer.
Standard UNIX applications such as newfs, fsck, mkfs, and mount, that normally take a disk device or raw disk device as a parameter, also accept the Subsystem Device Driver device as a parameter. Similarly entries in files such as vfstab and dfstab (in the format of cntndnsn) can be replaced by entries for the corresponding Subsystem Device Driver devices' vpathNs. Make sure that the devices that are replaced are replaced with the corresponding Subsystem Device Driver device. Running the showvpath command lists all Subsystem Device Driver devices and their underlying disks.
The procedures in this section show how to install Subsystem Device Driver for use with an Exported File System (Network File System file server).
Follow the instructions in this section if you are installing exported file systems on Subsystem Device Driver devices for the first time:
# newfs /dev/rdsk/vpathNs
In this example, N is the Subsystem Device Driver device instance of the selected volume. Create mount points for the new file systems.
Follow the instructions in this section if you have Network File System file server already configured for exported file systems that reside on a multiport subsystem, and if you want to use Subsystem Device Driver partitions instead of sd partitions to access them.
If there is a problem with any exported file system after completing step 6, restore the original /etc/fstab file and reboot to restore Network File System service. Then review your steps and try again.
Notes:
You can set up your Oracle database in one of two ways. You can set it up to use a file system or raw partitions. The procedure for installing your database differs depending on the choice you make.
Notes:
Your installation procedure for a new Subsystem Device Driver install will differ depending on whether you are using a file system or raw partitions for your Oracle database.
Follow this procedure if you are installing Subsystem Device Driver for the first time on a system with a Oracle database that uses a file system:
+--------------------------------------------------------------------------------+ |vpath0c | | c1t8d0s2 /devices/pci@1f,0/pci@1/scsi@2/sd@1,0:c,raw | | c2t8d0s2 /devices/pci@1f,0/pci@1/scsi@2,1/sd@1,0:c,raw | | | +--------------------------------------------------------------------------------+
If you would originally have used:
mount /dev/dsk/c1t3d2s4 /oracle/mp1
You now use:
mount /dev/dsk/vpath2e /oracle/mp1
(assuming you had found vpath2c to be the Subsystem Device Driver identifier)
Follow the instructions in Oracle Installation Guide for setting ownership and permissions.
Follow this procedure if you have Oracle8 already installed and want to reconfigure it to use Subsystem Device Driver partitions instead of sd partitions (for example, partitions accessed through /dev/rdsk/cntndn files).
If the Oracle8 installation is accessing Veritas logical volumes, go to Veritas Volume Manager for information about installing Subsystem Device Driver with that application.
All Oracle8 control, log, and data files are accessed either directly from mounted file systems, or through links from the oradata subdirectory of each Oracle mount point set up on the server. Therefore, the process of converting an Oracle installation from sd to Subsystem Device Driver has two parts:
Following are the conversion steps:
select * from sys.dba_data_files;
The output lists the locations of all data files in use by Oracle. Determine the underlying device that each data file resides on, either by looking up mounted file systems in /etc/vfstab or by extracting raw device link names directly from the select command output.
# ls -l /dev/rdsk/c1t1d0s4
You might see output that is similar to this:
+--------------------------------------------------------------------------------+ |/dev/rdsk/c1t1d0s4 /devices/pci@1f,0/pci@1/scsi@2/sd@1,0:e | +--------------------------------------------------------------------------------+
# ls -lL /dev/rdsk/c1t1d0s4
You might see output that is similar to this:
+--------------------------------------------------------------------------------+ |crw-r--r-- oracle dba 32,252 Nov 16 11:49 /dev/rdsk/c1t1d0s4 | +--------------------------------------------------------------------------------+
|For these procedures, you should have a copy of the Veritas
|Volume Manager System Administrator's Guide, and Veritas
|Volume Manager Command Line Interface for Solaris. These
|publications can be found at the following Web site:
| www.sun.com/products-n-solutions/hardware/docs/Software/Storage_Software/VERITAS_Volume_Manager/index.html
|
|
|
|Notice: Any references in this information to non-IBM Web
|sites are provided for convenience only and do not in any manner serve as an
|endorsement of those Web sites. The materials at those Web sites are
|not part of the materials for this IBM product and use of those Web sites is
|at your own risk.
These procedures were tested using Veritas 3.0.1. The Sun patches 105223 and 105357 must be installed with Veritas (this is a Veritas requirement).
Notes:
Follow the instructions in this section if you are installing Veritas on the multiport subsystem's server for the first time. Installing Veritas for the first time on a Subsystem Device Driver system consists of:
During installation, Veritas requires that at least one disk device be added to the Veritas root disk group (rootdg). This device must be a standard Solaris hard disk device, and not a Subsystem Device Driver device. It is important that the last disk in the rootdg be a regular disk and not a Subsystem Device Driver device. Therefore, it is recommended that you use a different disk group for your Subsystem Device Driver disks.
Subsystem Device Driver disks may only be added to a Veritas disk group as a whole, for example, any previous partitioning is ignored. The c partition (the whole disk) is used, so the Subsystem Device Driver device name for the disk in the /dev/dsk and /dev/rdsk directories would be vpath0c, for example. Veritas always looks in these directories by default, so only the device name is needed, for example, vpath0c, when issuing Veritas commands.
Partitioning of the given disk once it has been added to a Veritas disk group is achieved by dividing the Veritas disk into Veritas subdisks.
The following is an example of a command that adds a Subsystem Device Driver device to Veritas:
vxdisk -f init vpath0c
After running this command, the Veritas graphical user interface tool (VMSA) can be used to create a new disk group and, a new volume from a Subsystem Device Driver device.
Attention: VMSA and the command-line interface are the only supported methods of creating new disks or volumes with Veritas.
The following command creates a new disk group from the Subsystem Device Driver physical device. In this example, the new disk group is called ibmdg and the disk is vpath0c.
vxdg init ibmdg vpath0c
You can add a Subsystem Device Driver device to an existing disk group using the vxdgadd command.
This command gets the maximum size of the disk vpath0c in blocks:
/usr/sbin/vxassist -g ibmdg -p maxsize [vpath0c]
Write down the output of the last command and use it in the next command, which creates a volume called ibmv within the disk group called ibmdg.
The command to create a volume is:
/usr/sbin/vxassist -g ibmdg make ibmv 17846272 layout=nostripe
You can change the size of the volume and use less that the maximum number of blocks.
This section describes the Veritas command-line instructions needed to reconfigure a Veritas volume for use as a Subsystem Device Driver disk device. This reconfiguration consists of:
At the conclusion, you will have a disk group that contains twice the number of devices as the original disk group. The new Subsystem Device Driver devices in the disk group will be the same size as the original sd disks. The Solaris operating system will use the Subsystem Device Driver devices, and not the original sd disk.
The following procedure assumes that you have:
These instructions allow you to replace all sd references to the original hard disks that occur in the Veritas volume's configuration with references to the Subsystem Device Driver devices. The example provided shows the general method for replacing the sd device with the corresponding Subsystem Device Driver device in an existing Veritas volume.
The example uses the following identifiers:
A simplifying assumption is that the original volume, ibmv, contains exactly one subdisk. However, the method outlined here should be easy to adapt to other cases.
Before proceeding, record the multiport subsystem device links (/dev/(r)dsk/cntndnsn) being used as Veritas volume device files. Next, determine the corresponding Subsystem Device Driver device link (/dev/(r)dsk/vpathNs) using the showvpath command. Record this information.
vxdisk list c1t1d0
The resulting display includes information about the disk, including its public and private offset and length:
+--------------------------------------------------------------------------------+ |public: slice=4 offset=0 len=17846310 | |private: slice=3 offset=1 len=2189 | | | +--------------------------------------------------------------------------------+
From this information, calculate the parameters privlen (length of the private region) and puboffset (offset of the public region). In this case, privlen=2189, and puboffset=2190 because puboffset is one block more than the length of privlen.
vxdisk -f init vpath0c puboffset=2190 privlen=2189
vxdg -g rootdg adddisk disk02=vpath0c
umount /ibmvfs vxvol -g rootdg stop ibmv
vxprint ibmv
vxplex -g rootdg dis ibmv-01 vxvol -g rootdg set len=0 vol01
Attention: The plex should remain to serve as backup should backing out of the Subsystem Device Driver installation be necessary.
vxmake -g rootdg sd disk02-01 disk02,0,17846310(Use len from step 6)
vxmake -g rootdg plex ibmv-02 sd=disk02-01
vxplex -g rootdg att ibmv ibmv-02 vxvol set len=17846310 ibmv(Use length from step 6)
vxvol -g rootdg init active ibmv
Notes:
At this stage you can delete the original disk, after verifying that everything is working correctly.
For these procedures, you need access to the Solaris answerbook facility. These procedures were tested using Solstice DiskSuite 4.2, with the patch, 106627-04 (DiskSuite patch), installed. You should have a copy of the DiskSuite Administration Guide available to complete these procedures.
Notes:
Perform the following steps if you are installing Solstice DiskSuite on the multiport subsystem's server for the first time. The installation of Solstice DiskSuite for the first time on a Subsystem Device Driver system consists of:
Perform the following steps if Solaris DiskSuite is already installed:
metaclear <device> metainit -a
For these procedures, you need access to the Solaris answerbook facility.
Notes:
Perform the following steps if you are installing a new UFS logging file system on vpath devices:
Perform the following steps if you have UFS logging file systems already residing on a multiport subsystem and you wish to use vpath partitions instead of sd partitions to access them.
Create: metadb -a -c 3 -f vpath0f # add database replicas metainit d0 1 1 vpath0e # add metadevice Info metastat metadb -i Delete: metaclear d0 # delete metadevice metadb -d -f vpat
Attention: Do not reboot between the uninstall and the reinstall of the Subsystem Device Driver.
Upgrading the Subsystem Device Driver consists of uninstalling and reinstalling the IBMdpo package. Perform the following steps to uninstall the Subsystem Device Driver:
Attention: A number of different installed packages is displayed. Make sure you specify the correct package to uninstall.
A message similar to the following is displayed:
+--------------------------------------------------------------------------------+ |The following packages are available: | |1 IBMcli ibm2105cli | | (sparc) 1.1.0.0 | |2 IBMdpo IBM DPO driver Version: May-10-2000 16:51 | | (sparc) 1 | | | +--------------------------------------------------------------------------------+
+--------------------------------------------------------------------------------+ |## Removing installed package instance <IBMdpo> | | | |This package contains scripts that will be executed with super-user | |permission during the process of removing this package. | | | |Do you want to continue with the removal of this package [y,n,?,q] y | | | +--------------------------------------------------------------------------------+
+--------------------------------------------------------------------------------+ |## Verifying package dependencies. | |## Processing package information. | |## Executing preremove script. | |Device busy | |Cannot unload module: vpathdd | |Will be unloaded upon reboot. | |## Removing pathnames in class <none> | |/usr/sbin/vpathmkdev | |/opt/IBMdpo | |/kernel/drv/vpathdd.conf | |/kernel/drv/vpathdd | |/etc/rcS.d/S20vpath-config | |/etc/rc2.d/S00vpath-config | |/etc/defvpath | |## Updating system information. | | | |Removal of <IBMdpo> was successful. | | | +--------------------------------------------------------------------------------+
Attention: Do not reboot at this time.
When adding or removing multiport SCSI devices from your system, you must reconfigure Subsystem Device Driver to recognize the new devices. Perform the following steps to reconfigure the Subsystem Device Driver:
cd /opt/IBMdpo/bin
The Subsystem Device Driver provides commands that you can use to display
the status of adapters that are used to access managed devices, or to display
the status of devices that the device driver manages. You can also set
individual path conditions either to online or offline, or you can set all
paths that are connected to an adapter or bus either to online or
offline. This chapter includes descriptions of these commands. Table 21 provides an alphabetical list of these commands, a
brief description, and where to go in this chapter for more
information.
| Command | Description | Page |
|---|---|---|
| datapath query adapter | Displays information about adapters | datapath query adapter command |
| datapath query adaptstats | Displays performance information for all SCSI and FCS adapters that are attached to Subsystem Device Driver devices | datapath query adaptstats command |
| datapath query device | Displays information about devices | datapath query device command |
| datapath query devstats | Displays performance information for a single Subsystem Device Driver device or all Subsystem Device Driver devices | datapath query devstats command |
| datapath set adapter | Sets all device paths that are attached to an adapter to online or offline | datapath set adapter command |
| datapath set device | Sets the path of a device to online or offline | datapath set device command |
The datapath query adapter command displays information about a single adapter or all adapters.
Syntax
>>-datapath query adapter-adapter number-----------------------><
Parameters
Examples
If you enter the following command, datapath query adapter, the following output is displayed:
+--------------------------------------------------------------------------------+ |Active Adapters :4 | | | |Adpt# Adapter Name State Mode Select Errors Paths Active | | 0 scsi3 NORMAL ACTIVE 129062051 0 64 0 | | 1 scsi2 NORMAL ACTIVE 88765386 303 64 0 | | 2 fscsi2 NORMAL ACTIVE 407075697 5427 1024 0 | | 3 fscsi0 NORMAL ACTIVE 341204788 63835 256 0 | +--------------------------------------------------------------------------------+
The terms used in the output are defined as follows:
The datapath query adaptstats command displays performance information for all SCSI and FCS adapters that are attached to Subsystem Device Driver devices. If you do not enter a device number, information about all devices is displayed.
Syntax
>>-datapath query adaptstats-adapter number--------------------><
Parameters
Examples
If you enter the following command, datapath query adaptstats 0, the following output is displayed:
Adapter #: 0
=============
Total Read Total Write Active Read Active Write Maximum
I/O: 1442 41295166 0 2 75
SECTOR: 156209 750217654 0 32 2098
/*-------------------------------------------------------------------------*/
The terms used in the output are defined as follows:
The datapath query device command displays information about a single device or all devices. If you do not enter a device number, information about all devices is displayed.
Syntax
>>-datapath query device-device number-------------------------><
Parameters
Examples
If you enter the following command, datapath query device 35, the output is displayed as follows:
DEV#: 35 DEVICE NAME: vpath0 TYPE: 2105E20 SERIAL: 60012028 ================================================================ Path# Adapter/Hard Disk State Mode Select Errors 0 scsi6/hdisk58 OPEN NORMAL 7861147 0 1 scsi5/hdisk36 OPEN NORMAL 7762671 0
The terms used in the output are defined as follows:
The datapath query devstats command displays performance information for a single Subsystem Device Driver device or all Subsystem Device Driver devices. If you do not enter a device number, information about all devices is displayed.
Syntax
>>-datapath query devstats-device number-----------------------><
Parameters
Examples
If you enter the following command, datapath query devstats 0, the following output is displayed:
Device #: 0
=============
Total Read Total Write Active Read Active Write Maximum
I/O: 387 24502563 0 0 62
SECTOR: 9738 448308668 0 0 2098
Transfer Size: <= 512 <= 4k <= 16K <= 64K > 64K
4355850 1024164 19121140 1665 130
/*-------------------------------------------------------------------------*/
The terms used in the output are defined as follows:
The datapath set adapter command sets all device paths attached to an adapter either to online or offline.
Notes:
Syntax
>>-datapath set adapter-adapter number-+- online--+------------><
'- offline-'
Parameters
Examples
If you enter the following command, datapath set adapter 0 offline, adapter 0 changes to Offline mode and its state changes to failed; while all paths attached to adapter 0 change to Offline mode and their states change to Dead, if they were in the Open state.
The datapath set device command sets the path of a device either to online or offline.
Notes:
Syntax
>>-datapath set device-device number path number-+- online--+--><
'- offline-'
Parameters
Examples
If you enter the following command, datapath set device 0 path 0 offline, path 0 for device 0 changes to Offline mode.
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to:
IBM Director of LicensingFor license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to:
IBM World Trade Asia CorporationThe following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you.
Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact:
IBM CorporationSuch information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee.
The licensed program described in this document and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement or any equivalent agreement between us.
Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.
The following terms are trademarks of International Business Machines
Corporation in the United States, other countries, or both:
|
AIX Enterprise Storage Server IBM IBMLink OS/400 RS/6000 Subsystem Device Driver |
|
UNIX is a registered trademark of The Open Group in the United States and other countries
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States and/or other countries.
Other company, product, and service names may be trademarks or service marks of others.