and bay) with the device at that location in the recovered system configuration. This method is intended to handle replacement of devices. Note that not all I/O protocols support physical location addressing.

•Lunpath — Matching is done based on lunpath hardware path. This method matches the original persistent DSF associated with a lunpath hardware path with the device at that lunpath hardware path in the recovered system configuration. This method is intended to handle replacement of devices. Some protocols such as fibre channel have lunpath hardware paths and legacy hardware paths that are functionally different (use different hardware attributes).

•Legacy hardware path — Matching is done based on the legacy hardware path. This method matches the original persistent DSF associated with a legacy hardware path with the device at that legacy hardware path in the recovered system. This method matches devices using the same approach used for typical legacy DSFs.

Not all methods are appropriate for all protocols. The following are the ordered lists of persistent DSF-to-device matching methods by protocol. The order in which these methods are applied is important. Matching will be done in the order listed.

Table 4 Persistent DSF-to-device matching methods by protocol

Protocol

Ordered List

parallel SCSI

WWID, lunpath

fibre channel

WWID, physical location, lunpath

ide

lunpath

SAS

WWID, physical location, lunpath

other

no matching will be done

 

 

 

 

NOTE: There might be devices in the original system configuration that can not be matched with devices in the new system configuration. There might also be devices in the new system configuration that do not match devices in the original configuration. In these cases, the HP-UX operating system I/O drivers will assign legacy and persistent DSFs for the non-matching devices.

Controlling the I/O configuration process

It is possible to control the I/O configuration process associated with installation and recovery by using variables in the configuration file. These variables allow you to select disks that may be replaced with other disks, hide disks from the I/O configuration process, and control DSF naming.

By controlling the I/O configuration process, you can make configuration files that are general enough to use with clients having different hardware paths, protect disks from modification, and increase the performance of the I/O inventory process.

This section introduces the variables and value types associated with I/O configuration for use in configuration files. Further details can be found in instl_adm(4).

Table 5 I/O Configuration variables

I/O Configuration Variable

Description

allow_disk_remap

(boolean) Setting this to true allows Ignite to substitute a disk that was specified in the

 

configuration files but does not exist on the system with a disk that does exist and was

 

not specified to be used, hidden, or blocked. Default for this value is false for a

 

noninteractive installation, and true for an interactive installation. This is useful when

 

creating configuration files for use with multiple clients.

hide_boot_disk

(boolean) Setting this to true prevents the installation process from allowing the boot

 

disk to be configured and/or “cleaned”. This is useful only when the Ignite kernel is

 

booted from a dedicated hard disk you wish to protect from being modified.

Controlling the I/O configuration process 81