Version 1.4.1.1 =============================================================================== Multiple Instances of AIX on a Single Root Volume Group =============================================================================== This README serves only as clarification of specific issues discussed more completely in the other sources of documentation. Users are advised to review the multibos man page, the multibos sections in the Installation Guide and this README in its entirety before attempting to use the /usr/sbin/multibos utility. =============================================================================== CONTENTS =============================================================================== * TERMINOLOGY * UNDOCUMENTED OPERATIONS * SUPPORTED METHODS OF BACKUP/RECOVERY * NOTES REGARDING DUAL BOOT * MULTIBOS DATA FILES * USER SUPPLIED FILES * NOTES REGARDING MIGRATION =============================================================================== TERMINOLOGY =============================================================================== The running BOS instance is referred to as the active BOS. The non-running instance is referred to as the standby BOS. The active and standby terminology is only relevant in relation to the running instance. This terminology does not signify which instance derived the other. For further description, it is suggested that instances be referred by letters of affiliation. By following this suggestion, the original installation would always hold reference "A" and a new instance would hold reference "B". If "A" were removed and a new instance derived from "B", the preferred reference for the new instance is "C". On the other hand, if "B" were removed and a new instance created from "A", the new instance would be referred to as "B". This added terminology is necessary for two reasons: - it provides a means for relative (active and standby) and absolute (letter of affiliation) identification - the number of derivations is easily recognized (eg, "C" or "D" quickly show their distance from the original installation) =============================================================================== UNDOCUMENTED OPERATIONS =============================================================================== In addition to operations documented in the man page and publications, an undocumented verify operation is run from the inittab during boot. The inittab entry looks as such: mbverify:23456789:wait:/usr/sbin/multibos -V 2>&1 | alog -t boot > /dev/console It is highly recommended that the user not modify this entry. This verify operation allows the multibos utility to synchronize changes in logical volumes and filesystems between the active and standby instances. This entry also synchronizes the ODM and devices on initial boot after a mksysb restore. Without this operation, both the active and standby instances could become inconsistent with normal filesystem and logical volume operations. The verify operation only synchronizes data when the multibos utility recognizes that the system has changed the instance from which it is booting or that it is the first boot after a backup is restored. Therefore, it should be of little impact for consecutive boots from the same instance. If this inittab entry is blocked, removed or modified, the user is responsible for synchronization of the instances. This inittab entry (if runnable) is removed upon removal of the standby BOS (multibos -R). ** Additionally, see UNDOCUMENTED OPERATIONS PART 2. =============================================================================== SUPPORTED METHODS OF BACKUP/RECOVERY =============================================================================== Currently, the only supported method of backup and recovery of a rootvg with multiple instances is mksysb through CD, tape, or NIM. If the standby multibos instance has been removed and the active instance uses the traditional LV names (eg, no bos_ tag appended to the LV), other methods of backup and recovery of the rootvg are expected to work. If the standby BOS was mounted during the creation of the mksysb backup, it will be restored and synchronized on the first boot from the restored data. However, if the standby BOS was not mounted during the creation of the mksysb backup, the synchronization on reboot will remove the unusable standby BOS. NOTE: No Alternate Disk Installation operations are currently supported for this environment. The user should not confuse alt_disk_install mksysb or alt_mksysb with the above supported mksysb methods. =============================================================================== NOTES REGARDING DUAL BOOT =============================================================================== To keep track of the boot logical volume (BLV) that maps to the running boot image, the new device /dev/ipl_blv is a link to the active BLV device. The bosboot and rc.boot files manage the /dev/ipl_blv link. The /dev/ipldevice link still maps to the disk containing the boot image. By default, all operations map to the active BOS. This should provide for compatibility with all non-multibos user level operations. The chpv -c operation clears the boot record of the disk. Using this operation will clear mapping to both the active and standby BLVs. Care should be taken when using chpv -c. A bosboot operation on the active BLV will initialize the boot record mapping for the active BOS. In addition, the multibos bosboot operation (multibos -B) may be used to initialize the boot record mapping to the standby BOS. The -t option is used to block any change of the bootlist by the multibos utility. Whenever the multibos utility runs bootlist, the following header will be displayed in the output: +-----------------------------------------------------------------------------+ Bootlist Processing +-----------------------------------------------------------------------------+ Within the "Bootlist Processing" section of the output, the firmware recovery string will be displayed after the following message: ATTENTION: firmware recovery string for BLV (): The string should be noted and may be used as an additional method of controlling the boot. For example, something similar to the following may be displayed: ATTENTION: firmware recovery string for standby BLV (bos_hd5): boot /pci@fef00000/scsi@c/sd@4:4 ATTENTION: firmware recovery string for active BLV (hd5): boot /pci@fef00000/scsi@c/sd@4:2 If the bootlist command is not available (eg, the system is not currently running), the user might use the following command within the open firmware prompt (">") to boot (from hd5 as seen above): > boot /pci@fef00000/scsi@c/sd@4:2 Alternatively, the user might use the following to boot from bos_hd5: > boot /pci@fef00000/scsi@c/sd@4:4 If multibos bootlist changes are blocked and firmware recovery strings are not displayed, the user may use the bootlist command to set the bootlist and gain knowledge about the appropriate boot strings. The "blv=" option to bootlist should be used to specify the logical volume to boot from. For example: The -v option to the bootlist command displays the path to the boot image. As in the example above where the bootlist was set to first use bos_hd5 and next hd5 (if bos_hd5 is tagged as an invalid boot device), the bootlist output may produce the following: Path name: (/pci@fef00000/scsi@c/sd@4:4) hdisk0 blv=bos_hd5 Path name: (/pci@fef00000/scsi@c/sd@4:2) hdisk0 blv=hd5 The "Path name" output can be used to construct the firmware boot string. In the above output, /pci@fef00000/scsi@c/sd@4:4 is relevant to bos_hd5 and /pci@fef00000/scsi@c/sd@4:2 is relevant to hd5. =============================================================================== MULTIBOS DATA FILES =============================================================================== All log files are kept in the /etc/multibos/logs directory. The following are examples of files that may be found in this directory: - op.alog : A circular alog file of all multibos operations. - scriptlog..txt : A log of commands being run during the current shell operation. - scriptlog..txt.Z : A compressed log of commands run during a previous shell operation. In addition, the bootlog contains redundant logging of all multibos operations that occur during boot (eg, the verify that attempts synchronization from inittab). Multibos private data is stored in the /etc/multibos/data directory, the logical volume control block (LVCB) of logical volumes that were the source or target of a copy, and the /etc/filesystems entries that were the source or target of a copy. The following are examples of files found in the /etc/multibos/data directory: - acttag : The multibos tag for the active BOS. - sbyfslist : The list of filesystems private to the standby BOS. - sbylvlist : The list of logical volumes private to the standby BOS. - sbytag : The multibos tag for the standby BOS. The following may be seen in the fs field of the logical volumes that were the source or target of a copy: mb=:mbverify= The following may be seen in /etc/filesystems as an attribute of filesystems that were the source or target of a copy: mb = The user should not modify multibos private data. To prevent multibos operations from working simultaneously, the directory /etc/multibos/locks contains lock files. The following is an example of a file that may be found in this directory: - global_lock : The process ID (PID) of the currently running multibos operation. If a multibos operation exited unexpectedly and was not able to clean up, it may be necessary to remove this file. The user should check that the PID is not running before removing this file. =============================================================================== USER SUPPLIED FILES =============================================================================== Additional LVs may be copied into the standby BOS by using the -L flag during a setup operation. The format of the additional LV file is a newline separated list of logical volume names. The default logical volumes to be copied are hd1, hd2, hd4, hd5, hd9var, and hd10opt. Separate log device logical volumes are always shared and not supported for copy. If a separate log device is included in the LV copy list, it will not be copied. The following message will serve as indication that this occurred: multibos: 0565-096 Removing from copy list : device not supported for copy ** Additionally, see UNDOCUMENTED OPERATIONS PART 2. =============================================================================== NOTES REGARDING MIGRATION =============================================================================== Migration to 6.1 is currently not supported on systems with multibos enabled. Different multibos instances on the same system must be kept at the same version and release. Standby multibos instances must be removed before attempting a migration on such systems. =============================================================================== ADDITIONAL CORRECTIONS =============================================================================== Current documentation states that the following by default will be copied to the standby BOS during a setup operation: - boot logical volume - / fs and associated logical volume - /usr filesystem, contents and associated logical volume - /var filesystem, contents and associated logical volume - /opt filesystem, contents and associated logical volume - /home filesystem, contents and associated logical volume - log devices associated with any copied filesystem The log devices associated with copied filesystems are always shared and will not be copied (even if specified using -L). Also, by default /home will not be copied. =============================================================================== UNDOCUMENTED OPERATIONS PART 2 =============================================================================== VERIFY CONTROL SCRIPT(S) The multibos verify operation has been expanded to allow additional control scripts to be run when changing the instance of boot. To utilize this functionality, the user should create /etc/multibos/verify and place the runnable scripts in this directory. These scripts will be run on the reboot per the mbverify inittab entry (see UNDOCUMENTED OPERATIONS above) in sorted order. CUSTOMIZE CONTROL SCRIPT The multibos customize operation has been expanded to allow additional control script be run with the -x parameter. The -x parameter is valid only with the setup (-s) and customize (-c) operations. The syntax of -x is as follows: -x The customize script is run before any other customize parameters such as Update_all (-a), Install bundle file (-b), and Fix List file (-f). A valid image source directory (-l) must be supplied with the -x, just as with all other customize operations. To use the image source directory within the customize script, refer to /multibos_images. ATTENTION: To avoid corruption of the active instance, any installations done within the customize script MUST NOT rebuild the boot image. Refer to the installer's documentation for information on supressing boot image rebuilds. The customize operation correctly rebuilds the standby boot image (unless supplied the -N flag), making any boot image rebuild unnecessary within the customize script. NOTE: The customization script runs via chroot, so it is necessary to fully qualify all command calls and supply any script magic. =============================================================================== END OF DOCUMENT ===============================================================================