An alt_clone is an alternate disk copy of your rootvg. The alt_clone will backup all mounted jfs and jfs2 filesystems on your current rootvg and restore them to the disk that you choose.
One of its main uses is to upgrade your version of AIX to a higher Technology Level, (TL for short) or Service Pack, (SP for short) without impacting your current running rootvg. This would be beneficial, for example, in a situation where you find an application that is not compatible at a higher TL or SP, you can easily boot back to the working rootvg with minimal downtime.
Another functionality of the alt_clone command is that it can serve as a backup to your current rootvg. You can create a backup of your rootvg to a disk that is not being used.
alt_disk_mksysb clones your mksysb to the disk that you choose. The advantage to using this procedure is you can clone another server's mksysb to the disk and server that you choose.
You can upgrade your alt_disk_mksysb to a higher TL or SP and it can serve as a backup in case of an emergency.
Some of the requirements for alt_disk_mksysb are as follows:
- The mksysb must have all necessary device and kernel support required for the system it will be cloned to. You can not clone your mksysb and then add device support later.
- The bos.alt_disk_install.boot_images fileset has to be installed on the source server, (where the mksysb came from) and/or on the target server where alt_clone will take place.
- The version, release and TL of the bos.alt_disk_install.boot_images fileset must match the oslevel in the mksysb. So if the mksysb was created at 6.1TL5, the boot_images must be at 6.1.5.X.
- You can not clone a mksysb that is at a lower level against the server you are cloning to; meaning a 6.1TL5 mksysb can not be cloned to a 6.1TL7 server.
You need the bos.alt_disk_install package located on your AIX media. At AIX 5.3 and above, this package was included in the requisites list which means they were automatically installed when you first installed a server. There are 2 filesets contained in the bos.alt_disk_install package. You may want to verify both are installed by running the following command:
# lslpp -l |grep alt_disk
You will likely find you have these filesets installed:
bos.alt_disk_install.boot_images
bos.alt_disk_install.rte
# smitty alt_clone
(I am only including the fields you need to change in the smit examples.)
Clone the rootvg to an Alternate Disk
Type or select values in entry fields.
Press Enter AFTER making all desired changes.
[Entry Fields]
* Target Disk(s) to install [ hit F4 and select hdisk1]
This will clone your existing rootvg over to hdisk1.
From command line, you would run:
# alt_disk_copy –d hdisk1
Target Disk(s) to install [ hit F4 and select hdisk1]
Bundle to install [ hit F4 and choose “ update_all ”]
Directory or Device with images [ /
(required if filesets, bundles or fixes used)
installp Flags
ACCEPT new license agreements? Yes
From command line, you would run:
# alt_disk_copy -b update_all -l /
-or-
# alt_disk_copy -b update_all -l /dev/cd0 -d hdisk1
If you have an existing altinst_rootvg on hdisk1 and you want to update it as a separate step, you would first wake up the altinst_rootvg and run the following:
# alt_rootvg_op -W -d hdisk1
# alt_rootvg_op -C -b update_all -l /
-or-
# alt_rootvg_op -C -b update_all -l /dev/cd0
Note: It is imperative that you put the altinst_rootvg back to sleep once this operation is complete. See the next section for more information about the wake and sleep operations.
You may find the need to wake-up your altinst_rootvg. As in the example above where it was necessary to run an update_all on an existing alt_clone – you may also want to wake-up your alt_clone to access some data files in your altinst_rootvg. To wake up your altinst_rootvg disk, you would run the following:
# alt_rootvg_op -W -d hdisk1
When you have finished working with your altinst_rootvg you MUST put it back to sleep before rebooting.
# alt_rootvg_op -S
If you wake up the altinst_rootvg or the old_rootvg and you reboot without putting the alt_clone disk back to sleep, both rootvgs run the risk of being corrupted.
The corruption can manifest itself in several ways:
- Server hangs on reboot, (usually around LED 517, 518, 552 or 554 when it tries to varyon the rootvg or mount the rootvg filesystems).
- The ODM is corrupted, (command stops working or generate error messages after you run the command.)
- If your system does boot up you may see extended filesystem names such as: /alt_inst/alt_inst/var and logical volume names such as: alt_alt_hd9var
Also, the wake up command was designed to wake up the altinst_rootvg at the same level as the current rootvg or to wake the old_rootvg once we are booted to the altinst_rootvg. Waking up the altinst_rootvg which is running at a higher technology level compared to the current rootvg is not supported.
alt_disk_copy flags
-d target_disk(s) – This is a required flag. No alt_disk_copy command
works without it.
-b bundle_name - This flag is used to run a update_all. The -l flag must be used with this option.
-l images_location – The location of where your update filesets are located, (EX. –l /usr/sys/inst.images.)
-i image.data – Used if you have a customized image.data file. A common use of a custom image.data file would be to break the mirror on the rootvg so you can alt_clone a mirrored rootvg environment to one disk. Given rootvg is on hdisk0 and mirrored to hdisk1, your image.data file is located under /home/image.data and you want to clone to hdisk2, you would run the following:
# alt_disk_copy -i /home/image.data -d hdisk2
-B Prevents the alt_disk_copy command from setting the bootlist to the target disk after the successful completion of the operation.
alt_rootvg_op flags
-d target_disk – Needed for most rootvg_op commands except for the –X and -S flags.
-C Customization operation - This flag is needed if you want to run an update_all or any other customization to your altinst_rootvg.
-b bundle_name – Use this flag to specify a software bundle, (like the update_all bundle for example.) The -l flag must be used with this option.
-l images_location – Location of your update filesets.
-W Performs a wake-up on the root volume group located on the target_disk.
-S Puts to sleep the alternate root volume group that experienced a previous "wake" operation.
-t Once you “wake up” your altinst_rootvg, you can rebuild the boot image when you put the volume group back to sleep. This is useful in case you saw a bosboot error during your alt_clone process but you want to make sure that the boot image is valid on the altinst_rootvg. You have to use the -S with the -t flag.
-X Removes the altinst_rootvg or old_rootvg volume group definition from the ODM database.
EX. If you are booted off the altinst_rootvg and you want to remove the odm information for old_rootvg, you would run the following:
# alt_rootvg_op -X old_rootvg
Note that the -X flag only removes the volume group place holder for the altinst_rootvg or old_rootvg. It does not make any modifications to the actual disk, so it's still a bootable copy of the rootvg, even though you won't see the volume group in lsvg output anymore.
alt_disk_mksysb flags
-d target_disk(s) – The disk or disks you want to clone to.
-m Specifies the location of the mksysb that you want to clone. The value for device can be: Tape / CD device OR path name of mksysb image in a file system.
EX. If you want to clone a mksysb located under /usr/sys/inst.images to hdisk1, you would run the following:
# alt_disk_mksysb -m /usr/sys/inst.images/mksysb_filename -d hdisk1
-i image_data – Used if you have a customized image.data file. A common use of a custom image.data file would be to break the mirrors on the rootvg so you can install a mksysb backup with a mirrored rootvg environment to one disk
EX. If your rootvg was mirrored to hdisk0 & hdisk1 on the source system when you created the mksysb, and you want to alt_clone to a single disk, (hdisk2 on the target system, for example) using a customized image.data file located under /home/image.data, you would run the following:
# alt_disk_mksysb -m /usr/sys/inst.images/mksysb_filename -i /home/image.data -d hdisk2
Q: Can I run commands like bosboot or varyonvg to my altinst_rootvg or my old_rootvg?
A: No!!!! For bosboot: The only supported way to create a bootimage on the altinst_rootvg, is with the alt_rootvg_op –t flag. You must “wake up” the altinst_rootvg and run the following command to create the boot image:
# alt_rootvg_op -St
(The alt_disk_install command does not have a creating boot images flag.)
If you varyon the altinst_rootvg, it tries to varyon hd5, hd6, hd4, etc….to the mount points that are currently mounted on the running rootvg. AIX tries to merge both rootvgs and it’s a mess. From our standpoint, we can not recover from this and a mksysb restore is needed.
The best rule of thumb is to run commands that “look” at the LV data on the alt_clone and not write LV data to the alt_clone.
Q: I ran an 'alt_disk_install –X rootvg '/ 'alt_rootvg_op –X rootvg' by mistake and when i run lspv, my rootvg entry is gone. What do I do?
A: You can run these 2 commands to fix the issue:
# redefinevg -d hdisk0 rootvg
# synclvodm -Pv rootvg
Q: How come at 5.3, there are 3 alt_clone commands and only 1 command at 5.2?
A: Development realized that new functionality / flags could be introduced in later versions of AIX and it would look messy to have it all in one command. It was decided to break up the 'alt_disk_install' command into 3 commands mentioned earlier in this technote.
Q: What is the difference between alt_disk_install & alt_disk_copy?
A: alt_disk_install is a wrapper for the alt_disk_copy command. So when you run alt_disk_install, it’s actually running the alt_disk_copy command under the covers.
Q: I want to physically move my rootvg disk from one server to another. Is there a supported way for me to do that?
A: Yes. The -O flag was introduced for this feature. If you have an existing rootvg disk you can run the following command to clone hdisk0 to hdisk1. You can then physically remove hdisk1 and take it to another system.
EX.
# alt_disk_copy -B –O –d hdisk1
This performs a device reset on hdisk1. Using the safest method possible: You would then replace the altinst_rootvg placeholder in the ODM (# alt_rootvg_op -X altinst_rootvg), rmdev hdisk1, shutdown the server, physically remove that disk, go to another server that is powered down and plug in the disk. Power up the server and set the set disk as the boot device in SMS. It is not supported to simply pull a disk from one server and place it in another server without running through this process.
Q: Does alt_disk_copy convert JFS filesystems to JFS2?
A: Yes! Starting at 6100-04, a new flag was introduced that would convert JFS filesystems to JFS2. We now have the -T which does the conversion
No comments:
Post a Comment