HP Volume Shadowing for OpenVMS: OpenVMS Version 8.4 > Chapter 3 Preparing to Use Volume Shadowing

Booting from a System Disk Shadow Set

spacerspacerspacer
spacer
spacer
  		 
 

When multiple nodes boot from a common system disk shadow set, ensure that all nodes specify a physical disk that is a source member of the system disk shadow set.

At boot time, the volume shadowing software attempts to construct a complete system disk shadow set based on the shadowing membership information contained in the storage control block (SCB) of the boot device. The SCB is an ODS-2 or ODS-5 file system data structure that resides on each storage device and contains information about shadow set membership (described in “Shadow Set Consistency”). Depending on what information is in the SCB at boot time, the following scenarios are possible:

  • If the boot device is not formerly a member of a shadow set, the system creates a new shadow set containing only the boot device. You can manually mount additional disks into the shadow set after the system boot procedure completes. (See the Caution that follows.)

  • If the boot device is already a valid member of an existing shadow set (for instance, if it is already an up-to-date member of a shadow set mounted by another node in the cluster), the shadowing software automatically locates all the members of the set.

  • When booting the first node in a cluster, information stored in the SCB of the physical boot device is used to locate other members of the shadow set and to create the complete system disk shadow set.

  • The shadowing software detects boot attempts from a physical disk that is inconsistent with currently active shadow set members. In this case, the boot attempt detects the existence of the other shadow set members and determines (using the information in the SCB) that the boot device is not a valid member of the shadow set. When this occurs, the boot attempt fails with a SHADBOOTFAIL bugcheck message on the system console, and a dump file is written to the boot device.

    The system bugchecks because it can boot only from a currently valid member of the system disk shadow set. If the boot device fails out of or is otherwise removed from the system disk shadow set, you must either mount the boot device back into the shadow set (and wait for the copy operation to complete) or modify the boot command file to boot from a current shadow set member.

The boot process automatically locates all the members of a system disk shadow set. You must not add system disk shadow set members in startup procedures as formerly recommended when phase I shadowing was supported.

CAUTION: Do not add members to a system disk shadow set in startup procedures. Doing so can result in loss of data under the following circumstances:

  1. A system is operating normally with a multiple member system disk shadow set.

  2. The original boot device is removed from the shadow set but remains as a functioning disk.

  3. The system continues with the remaining members.

  4. The system is shut down or it fails.

  5. The system is rebooted using the original boot device (which is now out of date).

  6. The boot process determines that the boot device is not consistent with the other shadow set members and, therefore, does not add them into the shadow set. This behavior preserves the up-to-date data on the other members.

  7. A MOUNT command in the startup procedure adds the other shadow set members to the system disk shadow set.

  8. A copy operation from the boot device to the other shadow set members is initiated, thereby overwriting them.

If the boot device fails, the following console warning message displays:

virtual-unit: does not contain the member named to VMB. 
System may not reboot.

After the boot device has been repaired, manually add it back into the system disk shadow set.



Dynamic Volume Expansion (Integrity servers and Alpha)
  		 


Booting Satellite Nodes from a Served, System Disk Shadow Set