Recovery and the Agile View

During recovery, Ignite-UX C.7.x makes changes to the new system I/O configuration to match the original system I/O configuration. This is necessary because some aspects of a system configuration depend on the unpredictable order of system I/O inventory.

The overall goal of this process is to make the system I/O configuration appear as if the system simply rebooted at the time the recovery archive was created. This process is complex, and Ignite-UX might be unable to fully restore the I/O configuration. Ignite might not be able to restore aspects of the I/O configuration due to hardware changes, limitations of system I/O software, and limitations of Ignite-UX.

The system I/O configuration should be verified during and after recovery so configuration adjustments can be made if needed.

One part of restoring the I/O configuration is the appropriate matching of device special files (DSFs) and devices. There is one approach used for legacy DSFs in HP-UX 11i v3 and previous releases, and another approach used for HP-UX 11i v3 persistent DSFs.

Legacy DSFs and Device Matching

Matching legacy DSFs and mass storage devices is done based on hardware paths. Generally, legacy DSFs are associated with a particular hardware path. During recovery, a device is associated with its hardware path's DSF. (See Figure 16 (page 71) for a description of the legacy addressing model.)

Hardware configuration changes are handled by assuming a new device is intended to replace the device originally at that hardware path.

Note that some I/O protocols, such as SAS and USB, associate legacy DSFs with specific devices using unique LUN IDs, and so behave like persistent DSF matching described below.

SAS devices are a special case, since their legacy DSF/unique LUN ID association can change as a result of I/O configuration changes. If you change a SAS configuration (physically move a SAS device to another bay or remove a SAS device) the hardware path associated with that and other SAS devices can change during an installation or recovery. In such a case, hardware paths are reassigned to SAS devices. Since legacy DSFs are associated with a particular hardware path, a change in a device's hardware path breaks the association between its previous legacy DSF and its unique LUN ID. Note that the way SAS devices are associated during recovery might change in future versions of Ignite-UX to use the agile addressing approach described below.

Only certain SAS configuration changes cause remapping of hardware paths. For more information see the white paper, “Ignite-UX and SAS Devices” available at http://www.hp.com/go/ ignite-ux-docs.

Persistent DSFs and Device Matching

Matching persistent DSFs and mass storage devices is relatively complex due to agile addressing. Ignite-UX will attempt to simulate agile addressing during recovery, while also dealing with hardware replacement. This matching is accomplished using the methods described below:

•WWID — Matching is done based on the unique LUN ID of the device. Most often, this is the device's WWID. This method matches a device's original persistent DSF with the same device in the recovered system configuration.

•Device ID — (Future) Matching is done based on a user-definable identifier written to the device. This method matches a device's original persistent DSF with the device that has the same device ID in the recovered system configuration. This method allows user-provided identification to control device matching. Note that some mass storage devices do not support the device ID feature.

•Physical Location — Matching is done based on device physical location. This method matches the original persistent DSF associated with a particular physical location (e.g. same enclosure

80 Managing I/O for Installation and Recovery