Working With multibos
Although the multibos environment is transparent to the AIX OS in most cases, it's still important to be aware of the differences in order to effectively manage a multibos-enabled AIX system.
In my previous article on multibos I discussed using this tool to apply AIX* updates to a standby AIX instance. Here I’ll briefly discuss some of the considerations when managing a multibos-enabled AIX system.
In general, the multibos environment is transparent to the AIX OS. To system administrators and users, all commands will run as they normally do.
However, there are a few differences. For example, if you followed my procedure for applying AIX updates with multibos, you’ll find that the Base Operating System (BOS) logical volumes (LVs) in rootvg have the bos_ tag prepended to their names upon system restart. You’ll also observe that all the traditional LVs will be closed. See Figure 1.
This may initially cause you some concern. I admit I had the same reaction when I first came across this situation. However, it's OK to leave the system running with the new bos_ LV names. This is an IBM-supported configuration. It doesn’t impede the system, and given the benefits it can provide (e.g. reduced downtime for maintenance), it’s a small price to pay.
However if you really want your LV names to remain the same after applying maintenance or if some applications rely on legacy rootvg LV names, you can remove the previous BOS image (at the lower TL) and then create a new standby BOS and boot it. Your LV names will have the original names once more and you will still be on the later TL. However, you’ve just created the necessity for two reboots instead of one and removed your back out plan.
The bos_ LV names seem to concern many administrators—some are uneasy about running their systems with these LVs despite the support. Perhaps a future release of multibos will offer a different approach? As stated in my earlier article, if multibos doesn't fit your needs you can always use alternate disk installation instead.
Another difference is that more than one boot logical volume (BLV) will exist. In regards to this you should be careful of running the “chpv –c” command to clear the boot record on a disk. In a multibos environment this clears both instances of the BLV. Use the multibos “build boot image” (multibos –BX) operation to reform the boot image on the standby if this occurs.
Concerning backup and restore of rootvg, the only supported method of backup and recovery with multibos is mksysb via CD, NIM or tape. If the standby BOS was mounted during the creation of the mksysb, it is restored and synchronized on the first boot from the restored mksysb. However, if the standby BOS wasn’t mounted during the creation of the mksysb backup, the synchronization on reboot will remove the unusable standby BOS.
Since multibos isn’t supported, before migrating to AIX 6.1, ensure that your BOS LVs are back to their traditional names and that all standby BOS instances have been removed. If you want to perform AIX migrations with reduced downtime, I recommend nimadm (NIM Alternate Disk Migration).
Some other restrictions with multibos include:
- A maximum of two BOS instances are supported within rootvg.
- The total number of private LVs in rootvg must not exceed 128.
- A customized image.data file may not be used to add or delete BOS LVs or filesystems.
- Alternate Disk Installation operations aren’t currently supported with multibos. Don’t confuse alt_disk_mksysb with the traditional supported mksysb methods.
During boot an undocumented multibos verify operation is run from inittab. See Figure 2.
It’s highly recommended that you don’t modify this entry. This operation synchronizes changes in LVs and filesystems between the active and standby instances. It 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 LV operations. If this inittab entry is removed or modified, the administrator is responsible for synchronization of the instances. The entry is removed upon removal of the standby instance.
The rc.boot script has been modified to support multibos. To keep track of the BLV that maps to the running boot image, a new device (/dev/ipl_blv) was created that links to the active BLV device. See Figures 3.
Both the active and standby BLVs have a label to identify their purpose. See Figure 4.
The rc.boot script uses these labels to determine how a BLV should be re-labeled during boot, i.e. when booting between instances of the BOS, the standby becomes the primary on restart. See Figure 5.
Note that the bosboot command has new options to the –M flag (standby/primary) that tell it which BLV it should perform operations on. Don’t worry about this in normal operation.
The getlvcb command can assist in identifying active and standby BLVs by cross-referencing its output with the tags in /etc/multibos/data/acttag and /etc/multibos/data/sbytag. These tags are also stored in /etc/filesystems. See Figure 6.
Although the multibos environment is transparent to the AIX OS in most cases, it’s still important to be aware of the differences in order to effectively manage a multibos-enabled AIX system.
I encourage you to review the multibos readme file on your AIX system and become more familiar with the terminology and functions of the tool.