Introduction to Alt_Cloning on AIX 6.1 and 7.1

Answer


Introduction
What this document will cover
What this document will not cover
What is an alt_clone and why is it useful?
What is an alt_disk_mksysb and why is it useful?
What filesets need to be installed to run an alt_clone?
What commands do I need to run to create a basic alt_clone?
How do I create an alt_clone while updating it at the sametime?
How-to wake up the altinst_rootvg and put it to sleep
Useful flags for the alt_clone
Frequently Asked Questions, (FAQ)


Introduction

This guide is intended for those who are new to alternate disk cloning, (or alt_clone for short) and would like to understand the alt_clone process.

If you would like to learn more about alternate disk cloning, visit the IBM publib website and search on “alt_disk”. Link is provided below.

http://pic.dhe.ibm.com/infocenter/aix/v6r1/index.jsp?topic=/com.ibm.aix.ntl/releasenotes_kickoff.htm

For future reference, any device (cdrom, hdisk, or tape) will always be cd0, hdisk0 or rmt0 unless otherwise noted.
This document and the examples included will use "hdisk0" as our "rootvg" drive and "hdisk1" as our target "altinst_rootvg" drive.
You may, depending on your environment, need to use other devices...substitute as needed.

Finally, whenever there is an actual command to execute, it will look just like your command line interface on your AIX system.

For example if I want you to do a listing of files in a directory I would have:
# ls -al

What this document will cover

• Technology Level / Service Pack updates using alt_clone
• Command line and SMIT usage for the various “alt_” commands.
• How to safely manage your altinst_rootvg environment to avoid ODM corruption.
• Frequently Asked Questions

What this document will not cover

• Lesser used flags and operations (all of which can be found by following the infocenter link provided above).
• Any NIM related operations in conjunction with alt_disk_copy or alt_disk_mksysb

What is an alt_clone and why is it useful?

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.

What is an alt_disk_mksysb and why is it useful?

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.

(NOTE: Even though the alt_clone & alt_disk_mksysb are very reliable backups, it SHOULD NOT replace your mksysb or sysback backups.)

What filesets need to be installed to run an alt_clone?

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

What commands do I need to run to create a basic alt_clone?

# 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

How do I create an alt_clone while updating it at the same time?

# smitty alt_clone:

Target Disk(s) to install [hit F4 and select hdisk1]

Bundle to install [hit F4 and choose “update_all”]

Directory or Device with images [/<path to updates> -or- device to use (/dev/cd0)]
(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 /<path to updates> -d hdisk1
-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 /<path to updates>
-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.

How-to wake up the altinst_rootvg and put it to sleep

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.

Useful flags for the alt_clone

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

Frequently Asked Questions

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.