Alternate disk installation lets you install the operating system while it is still up and running, which reduces installation or upgrade downtime considerably. It also allows large facilities to better manage an upgrade because systems can be installed over a longer period of time. While the systems are still running at the previous version, the switch to the newer version can happen at the same time.
Alternate disk installation can be used in the following ways:
These methods can become important in environments where downtime is critical.
Alternate mksysb installation involves installing a mksysb image that has already been created from a system, onto an alternate disk of the target system. The alternate disk or disks cannot contain a volume group. The mksysb image is created on a system that either was the same hardware configuration as the target system, or had all the device and kernel support installed for a different machine type or platform, or different devices. The installed device and kernel support would be as follows:
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 are changed back to their original names at the end of the alternate disk installation process.
The mksysb image 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 are still 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 may 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 is not accidentally overwritten. The default action of alt_disk_install is to set the bootlist so that the next time the system boots, it boots from this newly installed volume group. This default action can be turned off. If specified, the system reboots at this point, and the system reboots 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.
After rebooting from the new alternate disk, the former rootvg volume group is contained in an lspv listing as old_rootvg, and includes all disk(s) in the original rootvg. This former rootvg volume group is set to not varyon at reboot and should only be removed with the -X flag. For example:
alt_disk_install -X old_rootvg
If a return to the original rootvg is necessary, the bootlist command is used to change the bootlist to reboot from the original rootvg.
If it is unclear which disk is the boot disk for a specific volume group, use the -q flag to determine the boot disk. This flag can be useful when a volume group is comprised of multiple disks and a change in the bootlist is necessary.
Cloning the rootvg to an alternate disk has many advantages. One advantage is having an online backup available, in case of a disk crash. Keeping an online backup requires an extra disk or disks to be available on the system. Another benefit of rootvg cloning occurs when 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 boots from the newly updated rootvg for testing. If updates cause problems, the old_rootvg can be retrieved by resetting the bootlist and then rebooting.
By default, calling the alt_disk_install command does the following:
For AIX 4.3.1 and later, 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 follows:
| Phase 1 | Creates the altinst_rootvg volume group, the alt_ logical volumes, and the /alt_inst file systems. Also restores the mksysb or rootvg data. |
| Phase 2 | Runs any specified customization script. For cloning only, installs updates, new filesets, fixes, or bundles. Also copies a resolv.conf file (if specified) and necessary files to remain a NIM client (if specified). |
| Phase 3 | Unmounts the /alt_inst file systems, renames the file systems and logical volumes, removes the alt_ logical volume names from ODM, and varies off the altinst_rootvg. It also sets the bootlist and reboots (if specified). |
As an alternative to running all three phases, the phases can be completed by one of the following methods:
You must run Phase 3 to obtain a usable rootvg. Running Phases 1 and 2 leave the /alt_inst file systems mounted. Any time during the phase process and before rebooting, the altinst_rootvg can be removed, and disk cleanup occurs using the following command:
alt_disk_install -X
Alternate disk migration installation allows the user to create a copy of rootvg to a NIM client's free disk (or disks) and simultaniously perform a migration installation using the Network Installation Management (NIM) environment. For more information on alternate disk migration installation, see the Alternate Disk Migration Installation section.
You can initiate data access between the original rootvg and the new alternate disk. A volume group "wake-up" can be accomplished, on the non-booted volume group. The "wake-up" puts the volume group in a post alt_disk_install Phase 1 state. For example, the /alt_inst file system is then mounted.
The volume group that experiences the "wake-up" is renamed altinst_rootvg.
When data access is no longer needed, the volume group can be "put to sleep."
Notes:
- The running operating system's version must be greater than or equal to the version of the volume group that undergoes the "wake-up." This might mean that it is necessary to boot from the altinst_rootvg and "wake-up" the old_rootvg. For example, an alternate disk is created from an alt_disk_install AIX 5.2 mksysb, on a AIX 4.3.0 system. It is then necessary to boot from the AIX 5.2 alternate disk and "wake-up" the AIX 4.3.0 old_rootvg volume group to access data between the two volume groups.
This limitation is caused by a journaled file system (JFS) log entry incompatibility. It is possible to "wake-up" a volume group that contains a more recent version, but the volume group cannot have ever been the system rootvg. If this was true, the volume group would have made JFS log entries that could not be interpreted by an older version rootvg, when the volume group was experiencing a "wake-up."
The alt_disk_install command does not allow a "wake-up" to occur on a volume group with a more recent version, unless the FORCE environment variable is set to yes.
- The volume group that experiences a "wake-up" must be put to sleep before it can be booted and used as the rootvg.
Attention: If a FORCE "wake-up" is attempted on a volume group that contains a more recent version of the running operating system, and the "waking" volume group has been a system rootvg, errors occur.
An alternate disk installation uses the following filesets:
| bos.alt_disk_install.boot_images | Must be installed for alternate disk mksysb installations. |
| bos.alt_disk_install.rte | Must be installed for rootvg cloning and alternate disk mksysb installations. |
The graphical interface provides access to Web-based System Manager options for installing a mksysb to an alternate disk and for cloning a rootvg to the alternate disk. At any time during the following procedures, you can view extended help by selecting Contents from the Help menu.
To install a mksysb to an alternate disk, do the following:
To clone the rootvg to an alternate disk, do the following:
To run alternate disk mksysb installation, do the following:
To run alternate disk rootvg cloning, do the following:
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 /433fixes \ -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, type /433fixes in the Directory or Device with images field, and type /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_52_mksysb -i /mksysbs/my_52_image.data \ -e /mksysbs/my_exclude_file hdisk2
Using the ^./tmp/ pattern does not backup files in the /tmp directory, but does backup files in /var/tmp.
Note: All files are backed up relative to the current directory. This directory is represented by a . (dot character). If it is important that the search match the string at the beginning of the line when excluding a file or directory, it is necessary to use a ^. (caret followed by a dot character) as the first part of the search string, followed by the filename or directory to be excluded. The form is as follows:^./filenameIf the filename or directory being excluded is a substring of another filename or directory, use a ^. (caret followed by a dot character) for the search to start at the beginning of the line and the $ (dollar symbol) to have the search finish at the end of the line.
In SMIT, use the smit alt_mksysb fast path and select hdisk2 in the Target Disk(s) to install field. Next, type /mksysbs/my_52_mksysb in the Device or image name field, /mksysbs/my_52_image.data in the image.data file field, and /mksysbs/my_exclude_file in the Exclude list field.
alt_disk_install -W hdisk0
The following example illustrates the displayed output you might see when running the command discussed above:
# lspv hdisk0 000040445043d9f3 old_rootvg hdisk1 00076443210a72ea rootvg # alt_disk_install -W hdisk0 # lspv hdisk0 000040445043d9f3 altinst_rootvg hdisk1 00076443210a72ea rootvg
At this point, the altinst_rootvg volume group is varied-on and the /alt_inst file systems are mounted.
alt_disk_install -S
The following example illustrates the output you might see when running the command previously discussed:
# lspv hdisk0 000040445043d9f3 altinst_rootvg hdisk1 00076443210a72ea rootvg # alt_disk_install -S # lspv hdisk0 000040445043d9f3 altinst_rootvg hdisk1 00076443210a72ea rootvg
The altinst_rootvg is no longer varied on and the /alt_inst file systems are no longer mounted. If necessary for the altinst_rootvg volume group name to be changed back to old_rootvg, do this task with the -v flag.