Alternate disk installation, available in AIX Version 4.3, allows installing the system while it is still up and running, allowing install or upgrade down time to be decreased considerably. It also allows large facilities to manage an upgrade because systems can be installed over a longer period of time while the systems are still running at the same version. The switchover to the new version can then happen at the same time.
Alternate disk installation can be used in one of two ways:
Both of these functions can become important in environments where down time is critical (sometimes called 7 X 24 environments).
Alternate mksysb install involves installing a mksysb image that has already been created from another system, onto an alternate disk of the target system. The alternate disk or disks cannot contain a volume group unless Phase 1 of alt_disk_install has previously been executed. In this case, the associated volume group is altinst_rootvg (see "Phased Alternate Disk Installation"). The mksysb image (AIX Version 4.3 or later) would be created on a system that was either the same hardware configuration as the target system, or would have all the device and kernel support installed for a different machine type or platform, and/or different devices. The installed device and kernel support would be:
When the alt_disk_install command is run, the image.data file from the mksysb image is used by default (unless a customized image.data is given) to create the logical volumes and file systems. The prefix alt_ is added to the logical volume names, and the file systems are created with a prefix of /alt_inst. For example, hd2 would be created as alt_hd2, and its file system, /usr, would be created as /alt_inst/usr. These names will be changed back to their original names at the end of the alternate disk installation process.
The mksysb is then restored into the alternate file system. A prepopulated boot image is then copied to the boot logical volume of the altinst_rootvg, and the boot record of the boot disk is modified to allow booting from the disk.
At this point, a script can be run to allow for any customization before the system is rebooted. The alternate file systems will still be mounted as /alt_inst/real_file_system (for example: /alt_inst/usr, /alt_inst/home). Files can be accessed at this point, but nothing can be installed into the alternate file system because the kernels and libraries of the mksysb image do not match those of the running system.
After the optional script is run, the file systems are unmounted, and the logical volume and file system names are changed to match the image.data file's names (for example, alt_inst_hd6 is changed to hd6 in the volume group descriptor area). The logical volumes are exported from the Object Data Manager (ODM), but the altinst_rootvg is only varied off. It is left in the ODM as a placeholder so the disk will not be accidentally overwritten. The default action of alt_disk_install would then be to set the bootlist so that the next time the system boots, it will boot from this newly installed volume group. This default action can be turned off. If specified, the system will reboot at this point, and the system will reboot from the new rootvg. The boot process proceeds to a certain point, with the new rootvg's file systems mounted, and the bosboot command is called to rebuild a "normal" boot logical volume. The system then reboots.
Once the system has booted from the new rootvg, the "old" rootvg does not appear in logical volume manager (LVM) listings, but if desired, the bootlist can be changed to boot from the old rootvg boot disk.
Cloning the rootvg to an alternate disk can have many advantages. One advantage is having an online backup available, in case of disaster. Keeping an online backup would require an extra disk or disks to be available on the system. Another benefit of rootvg cloning is in applying new maintenance levels or updates. A copy of the rootvg is made to an alternate disk, then updates are applied to that copy. The system runs uninterrupted during this time. When it is rebooted, the system will boot from the newly updated rootvg for testing. If updates cause problems, the old rootvg can be retrieved by simply resetting the bootlist and rebooting.
When the alt_disk_install command is called, it will, by default, create an image.data file based on the current rootvg's configuration. A customized image.data file can be used. An alternate rootvg (altinst_rootvg) is then created, and the logical volumes and file systems are then created with the alt_inst prefix. A backup file list is then generated from the rootvg, and if an exclude.list file is given, those files will be excluded from the list. The final list is then copied to the altinst_rootvg's file systems.
At this point, if specified, installp will install updates, fixes, or new filesets into the alternate file system. Next, bosboot will create a boot logical volume on the alternate boot disk.
If a customization script is specified, it will run at this point. The file systems are then unmounted, and the logical volumes and file systems are renamed. The logical volume definitions are exported from the system to avoid confusion with identical ODM names, but the altinst_rootvg definition will be left as an ODM placeholder.
By default, the bootlist will be set to the new cloned rootvg for the next reboot.
Beginning with AIX Version 4.3.1, alternate disk installation can be performed in stages. The installation itself is broken down into three phases. The default is to perform all three phases in the same invocation. The phases are:
As an alternative to running all three phases, the phases can be executed in the following ways:
You must run Phase 3 to obtain a usable rootvg. Running Phases 1 and 2 will leave the /alt_inst file systems mounted. Any time during the phase process, before rebooting, the altinst_rootvg can be removed, and disk cleanup will occur, using the following command:
alt_disk_install -X
Note: This task is not currently supported by Web-based System Manager.
To run alternate disk mksysb install:
smit alt_mksysb
To run alternate disk rootvg cloning:
smit alt_clone
alt_disk_install -C -b update_all -l /dev/cd0 hdisk1
In SMIT, use the smit alt_clone fast path and select hdisk1 from the listing for Target Disk(s) to install, select the update_all bundle from the listings in the Bundle to Install field, and /dev/cd0 from the listing in the Directory or Device with images field.
alt_disk_install -C -b update_all -l /421fixes \ -s /tmp/finish_alt_install hdisk3
In SMIT, use the smit alt_clone fast path and select hdisk3 from the listing for Target Disk(s) to install, select the update_all bundle from the listings in the Bundle to Install field, enter /421fixes in the Directory or Device with images field, and type in /tmp/finish_alt_install in the Customization script field.
alt_disk_install -d /dev/rmt0 hdisk1
In SMIT, use the smit alt_mksysb fast path and select hdisk1 from the listing for Target Disk(s) to install field and select /dev/rmt0 from the listing for Device or image name field.
alt_disk_install -d /mksysbs/my_43P_mksysb -i /mksysbs/my_43p_image.data hdisk2
In SMIT, use the smit alt_mksysb fast path and select hdisk2 from the listing for Target Disk(s) to install field. Enter /mksysbs/my_43P_mksysb in the Device or image name field, and enter /mksysbs/my_43p_image.data in the image.data file field.
If you receive either of the following two error messages, see "Acting on System and Error Messages"
Symptom: You are trying to install the bos.alt_disk_install.rte fileset on a Version 4.1 system, and installp is giving an error that requisites are not being met, but it does not indicate what the requisites are.
This problem is a Version 4.1 installp limitation in not reporting the requisites. The bos.alt_disk_install.rte requires the bos.sysmgt.sysbr (the mksysb fileset) to be installed at the same level as the running system. Therefore, if you are attempting to install on a Version 4.1.5 system, then bos.sysmgt.sysbr 4.1.5.0 should also be installed.
Symptom: You have run the alt_disk_install command or used the SMIT menus to either clone or install a mksysb image on an alternate disk. However, you now want to remove the definition so you can use the disk to run alt_disk_install again or use the disk for another purpose.
Action: Do not run exportvg. The exportvg examines the logical volumes on the disk (now called by their rootvg names: hd1, hd2, hd3, and so on) and tries to remove their corresponding entries from the /etc/filesystems file. This action will remove the real file system stanzas from your running system and will cause boot problems if you reboot with the missing stanzas.Use the alt_disk_install -X command to remove the altinst_rootvg name from the database. This will remove only the ODM information from the CuDv database, so the lspv command will show the disk(s) as no longer belonging to altinst_rootvg. It will also reset your bootlist to the boot disk where the hd5 boot logical volume resides. You can still boot from the altinst_rootvg, since the volume group, logical volume, and file system information remain on the disk. However, you will need to set your bootlist to the altinst_rootvg boot disk.