scsimgr SCSI Management and Diagnostics utility on HP-UX 11i v3 (March 2008)

be put in “Authentication failure”. In this case it is more convenient for the user to validate the change

by specifying the target paths. All lunpaths beneath each target path specified will be validated.

Since the number of target paths is very limited compared to the number of lunpaths or disks affected,

the system administrator will have to run ‘scsimgr replace_wwid’ only a few times. The system

administrator can use target information provided in the logging as shown in the example below.

# scsimgr -f replace_wwid -C tgtpath -I 3

scsimgr: Successfully validated binding of LUN paths with new LUN.

Note: If verbose output is requested with the -v option, scsimgr displays each lunpath for which the

replacement is validated. The following example shows a verbose output for target path with several

lunpaths beneath it.

# scsimgr -v -f replace_wwid -C tgtpath -I 10

Binding of LUN path 0/4/1/0/4/0.0x50001fe150006e69.0x0 with new LUN validated successfully

Binding of LUN path 0/4/1/0/4/0.0x50001fe150006e69.0x4001000000000000 with new LUN validated

successfully

Binding of LUN path 0/4/1/0/4/0.0x50001fe150006e69.0x4002000000000000 with new LUN validated

successfully

Binding of LUN path 0/4/1/0/4/0.0x50001fe150006e69.0x4003000000000000 with new LUN validated

successfully

Binding of LUN path 0/4/1/0/4/0.0x50001fe150006e69.0x4004000000000000 with new LUN validated

successfully

Note: If the target path is specified to validate the change, scsimgr cannot re-assign the DSFs of the

replaced disks to the new disks. You should either reconfigure the applications, which were using the

replaced disks, or invoke the io_redirect_dsf script for each replaced disk.

Validating change of the binding of legacy DSFs to LUNs

In HP-UX 11i v3 legacy DSFs and persistent DSFs coexist. A legacy DSF represents a path to the LUN.

By default the native multi-pathing is enabled on legacy DSFs. It means that even if the lunpath

corresponding to a legacy DSF becomes unavailable, applications using it can continue to transfer

data to the device through other available lunpaths. This behavior affects how the SCSI stack deal

with reconfigurations impacting legacy DSFs.

In releases prior to HP-UX 11i v3, if a new LUN is discovered at a specific lunpath, the corresponding

legacy DSF is automatically associated with the new LUN. In HP-UX 11i v3 the SCSI stack maintains

internally the binding between a legacy DSF and a LUN. If a new LUN is discovered at a specific

path, the SCSI stack keeps the existing binding between the corresponding legacy DSF and the LUN

previously discovered at this path until the change is explicitly validated or the system is rebooted.

This allows applications using the affected legacy DSF to continue to perform I/O transfers to the

device previously seen at this path, through other available paths.

Notes:

• Various SAN reconfigurations can impact legacy DSF. In cases where the system

administrator has to explicitly confirm the change of the binding between a legacy DSF and a

LUN, the SCSI stack logs a message and the recommended action in

/var/adm/syslog/syslog.log and on the console. The system administrator should rely on

these messages and perform the action indicated to validate the change.

• Even in case a message is logged, the system administrator may choose not to confirm the

change for example to allow applications using the legacy DSF to continue I/O transfers

through other available paths. However, if the system is rebooted some time later, that legacy

DSF will be bound to the new LUN. This could impact applications or upper layers using this