Installs an alternate disk with a mksysb install image or clones the currently running system to an alternate disk.
- Create Alternate Disk:
- alt_disk_install {-d device | -C} [-i image.data] [-s script ] [-R resolv_conf] [-D] [-B] [-V] [-r]
- [-p platform ] [-L mksysb_level ]
- [-b bundle_name ] [-I installp_flags ]
- [-l images_location ] [-f fix_bundle ]
- [-F fixes ] [-e exclude_list ] [-w filesets ]
- [-n] [-P phase_option ] target_disks...
- Clean Up Alternate Disk Volume Group:
- alt_disk_install -X
For alt_disk_install 4.3.2 or greater:
- Determine Volume Group Boot Disk:
- alt_disk_install -q disk
- Put-to-sleep Volume Group:
- alt_disk_install -S
- Rename Alternate Disk Volume Group:
- alt_disk_install -v new_volume_group_name disk
- Wake-up Volume Group:
- alt_disk_install -W disk
- Clean Up Alternate Disk Volume Group:
- alt_disk_install-X [ volume_group]
The alt_disk_install command allows users a way to update AIX to the next release or maintenance level, without taking the machine down for an extended period of time. This can be done in two ways, by installing a mksysb image on a separate disk, or by cloning the current system and then applying updates to get to the next maintenance level.
The first function, installing a mksysb, requires a 4.3 mksysb image, a 4.3 mksysb tape, or a 4.3.3 mksysb CD. The alt_disk_install command is called with a disk or disks that are not currently in use, and the mksysb is restored to those disks such that, if the user chooses, the next reboot boots the system on a 4.3 system.
Note: If needed, the bootlist command can be run after the new disk has been booted, and the bootlist can be changed to boot back to the older version of AIX.
The second function, cloning the running rootvg, allows the user to create a backup copy of the root volume group. This copy could be used as a back up in case the rootvg failed, or it could be modified by installing additional updates. One scenario might be to clone a 4.2.0 system, then install updates to bring the cloned rootvg to 4.2.1.0. This would update the system while it was still running, then rebooting from the new rootvg would bring the level of the running system to 4.2.1. If there was a problem with this level, changing the bootlist back to the 4.2.0 disk and rebooting would bring the system back to 4.2.0. Other scenarios would include cloning the rootvg and applying individual fixes, rebooting the system and testing those fixes, and rebooting back to the original rootvg if there was a problem.
Currently, you can run the alt_disk_install command on 4.1.4.0 and higher systems for both of these functions. The bos.alt_disk_install.rte fileset must be installed on the system to execute the alt_disk_install command, and the bos.alt_disk_install.boot_images fileset must also be installed to perform a mksysb install to an alternate disk.
The mksysb image that is used must be created ahead of time and have all the necessary device and kernel support required for the system that it's going to be installed on. No new device or kernel support can be installed before the system is rebooted from the newly installed disk.
Note: The version release maintainence level of mksysb that you are installing must match the level of the bos.alt_disk_install.boot_images fileset.
When cloning the rootvg volume group, a new boot image is created with the bosboot command. When installing a mksysb image, a boot image for the level of mksysb and platform type is copied to the boot logical volume for the new alternate rootvg. When the system is rebooted, the bosboot command is run in the early stage of boot, and the system is rebooted once again. This is to synchronize the boot image with the mksysb that was just restored. The system then boots in normal mode.
At the end of the install, a volume group, altinst_rootvg, is left on the target disks in the varied off state as a place holder. If varied on, it shows as owning no logical volumes, but it does indeed contain logical volumes, but they have been removed from the ODM because their names now conflict with the names of the logical volumes on the running system. It is recommended that you not vary on the altinst_rootvg volume group, but just leave the definition there as a place holder.
After the system reboots from the new alternate disk, the former rootvg volume group does not show up in a lspv listing, unless the alt_disk_install version is 4.3.2 or higher.
For alt_disk_install 4.3.2 or greater:
After rebooting from the new alternate disk, the former rootvg volume group shows up in a 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 (i.e. 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.
For alt_disk_install 4.3.2 or greater:
If it is unclear which disk is the boot disk for a specific volume group, the -q flag can be used to determine the boot disk. This can be useful when a volume group is comprised of multiple disks and a change in the bootlist is necessary.
The alternate root file system is mounted as /alt_inst, so other file systems would have that prefix (/alt_inst/usr, /alt_inst/var). This is how they should be accessed if using a customization script.
Attention: If you have created an alternate rootvg with alt_disk_install, but no longer wish to use it, or want to run alt_disk_install commands, do not run exportvg on altinst_rootvg.
Simply run the alt_disk_install -X command to remove the altinst_rootvg definition from the ODM database. The reason you cannot run the exportvg command (or the reducevg command) is that the logical volume names and file systems now have the real names, and exportvg removes the stanza's for the real file system from /etc/filesystems for the real rootvg.
If exportvg is run by accident, be sure to recreate the /etc/filesystems file before rebooting the system. The system will not reboot without a correct /etc/filesystems file.
This function is also available with the Network Installation Management (NIM). See the NIM Guide for more information.
The AIX Version 4.3.1 and greater version of alt_disk_install can be executed in phases. The install is divided into three phases, and the default is to perform all three phases.
You can run each phase separately, run Phases 1 and 2 together, or run Phases 2 and 3 together. Phase 2 can be run multiple times before Phase 3 is run.
You must run Phase 3 to get a volume group that is a usable rootvg. Running Phase 1 and 2 leaved the /alt_inst file systems mounted.
If you have run Phase 1 and or Phase 2, and want to start over (remove the altinst_rootvg), run the alt_disk_install-x command to clean up.
For alt_disk_install 4.3.2 or greater:
If data access is necessary between the original rootvg and the new alternate disk, a volume group "wake-up" can be accomplished, using the -W flag, on the non-booted volume group. The "wake-up" puts the volume group in a post alt_disk_install phase 1 state (i.e. the /alt_inst file systems will be mounted).Note: The volume group that experiences the "wake-up" will be renamed "altinst_rootvg".Limitation
The running system's version of AIX must be greater than or equal to the AIX version of the volume group that undergoes the "wake-up". This may mean that it's 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 4.3.3 mksysb, on a 4.1.5 running system. To access data between the two volume groups, it is necessary to boot from the 4.3.3 alternate disk and "wake-up" the 4.1.5 "old_rootvg" volume group.This limitation is caused by a jfs log entry incompatibility. It is possible to "wake-up" a volume group that contains a greater AIX version, but the volume group could not have ever been the system rootvg. If so, the volume group would have made jfs log entries that could not be interpreted by an older AIX version rootvg, when the volume group was experiencing a "wake-up". JFS log entries are usually present for file systems that were not unmounted before a reboot, for example, /,/usr.
The alt_disk_install command will not allow a "wake-up" to occur on a volume group with a greater AIX version, unless the FORCE environment variable is set to "yes".
Attention: If a FORCE "wake-up" is attempted on a volume group that contains a greater AIX version then the running OS, AND the "waking" volume group has been a system rootvg, errors will occur.
When data access is no longer needed, the volume group can be put to sleep, using the -S flag.
Note: The volume group that has experienced a "wake-up" MUST be "put-to-sleep" before it can be booted and used as the rootvg.
The following flags are only valid for use when cloning the rootvg (-C).
The following flags are available for alt_disk_install version 4.3.2 or greater:
Limitation
The running system's version of AIX must be greater than or equal to the AIX version of the volume group that undergoes the "wake-up". This may mean that it's necessary to boot from the "altinst_rootvg" and "wake-up" the "old_rootvg".
target_disks | Specifies the name or names of the target disks where the alternate rootvg will be created. This disk or these disks must not currently contain any volume group definition. The lspv command should show these disks as belonging to volume group None. |
alt_disk_install -C -F 4.2.1.0_AIX_ML -l /updates hdisk3
The bootlist would then be set to boot from hdisk3 at the next reboot.
alt_disk_install -d /mksysb_images/4.3_mksysb -s /home/myscript hdisk3
alt_disk_install -X old_rootvg
The lspv listing for the original rootvg will be changed to "None". Therefore, a new volume group could be created on those disks.
alt_disk_install -q hdisk0
Illustrated Example
# lspv hdisk0 00006091aef8b687 old_rootvg hdisk1 00076443210a72ea rootvg hdisk2 0000875f48998649 old_rootvg # alt_disk_install -q hdisk0 hdisk2
In this case, the boot disk for "old_rootvg" is actually hdisk2. Therefore, you could reset your bootlist to hdisk2 and reboot to the original rootvg volume group.
alt_disk_install -v alt_disk_432 hdisk2
Illustrated Example
# lspv hdisk0 00006091aef8b687 rootvg hdisk1 00000103000d1a78 rootvg hdisk2 000040445043d9f3 altinst_rootvg hdisk3 00076443210a72ea altinst_rootvg hdisk4 0000875f48998649 None hdisk5 000005317c58000e None # alt_disk_install -v alt_disk_432 hdisk2 #lspv hdisk0 00006091aef8b687 rootvg hdisk1 00000103000d1a78 rootvg hdisk2 000040445043d9f3 alt_disk_432 hdisk3 00076443210a72ea alt_disk_432 hdisk4 0000875f48998649 None hdisk5 000005317c58000e None
alt_disk_install -W hdisk0
Illustrated Example
# 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 will be mounted.
alt_disk_install -S
Illustrated Example
# 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 it's necessary for the "altinst_rootvg" volume group name to be changed back to "old_rootvg", this can be done with the "-v" flag.
/usr/sbin/alt_disk_install | Contains the alt_disk_install command |
The bootlist, nim, lspv, and bosboot commands.