AIX Cloning

Mark E. Dawson, Jr.

"If only I could replace the IT department with clones of Bob, we'd be in much better shape." No doubt, we've all heard similar sentiments expressed during our careers, and may have even expressed them ourselves. We have an obvious enthusiasm for the whole subject of cloning, as it is a frequent topic in scientific magazines and in popular movies. Although the ramifications and moral implications of cloning are still unknown, cloning is widely regarded as a welcomed functionality within the computer technology field.

Of course, the general idea is that the attributes of one object are duplicated on another similar object. As a matter of fact, UNIX engineers in general perform cloning at various levels to aid productivity. For example, an administrator may copy the environment (attribute) created on one UNIX box (object) onto all others on which he'll work (e.g., copying the .profile, .login, .cshrc, or .kshrc files, or copying the .exrc file to make those vi macro customizations available on other workstations). However, a more useful and time-saving application would be a simple procedure of cloning UNIX servers. Perhaps you need to migrate one server's functions onto a more powerful server, or you'd like an exact representation of your production server's configuration on another server for testing purposes. You can probably think of a few more useful cases where cloning would benefit your environment, but the overall idea is that such functionality can greatly aid a systems administrator.

AIX, IBM's UNIX, provides such a useful cloning feature. It is largely due to the presence of the ODM (Object Data Manager), a central repository in which AIX keeps device information, that the cloning procedure works. Let's consider an example of cloning the image of one machine architecture onto another machine of a different architecture, then I will explain why it works.

Cloning Scenario

Suppose you have an old 7015-R40 SMP box with 2 CPUs that serves as your backup server. You figured that this old classical RISC box has had it, and you want to play around with some of the PowerPC RISC models anyway. Therefore, you order a dual-processor F50 PowerPC box and prepare to migrate the R40's image onto the new machine. Both are running AIX 4.3.3. The steps are as follows:

On the source system (R40):

1. Create an image backup of the R40 to tape with "mksysb -i /dev/rmt0".

On the target system (F50):

1. Boot from the AIX 4.3.3 install CD into Service Mode. On the F50, this can be done by pressing the F5 key after powering on the machine with the install CD in the CD-ROM drive. Keep pressing the F5 key until you see that the system has successfully begun to boot from CD, so as not to miss the window during which the boot process looks for any key interrupts.

2. A message requesting you to press "F1 or 1 for the system console" will appear, at which time you'll hit one of these keys.

3. A menu will appear, presenting you with 3 options. Select option #3 -- "Start Maintenance Mode for System Recovery".

4. The next menu screen will present 4 more options. Select option #4 -- "Install from a System Backup".

5. You'll be prompted to choose a tape drive. Place the mksysb tape that was created on the source (R40) system, wait for the tape drive to finish retentioning, then select the appropriate tape device from the menu.

6. Another menu will appear. Select option #2 -- "Change/Show Installation Settings and Install." From this selection, you can specify which disks on the target system (F50) that you want the image installed onto (or just leave them at the AIX defaults) and decide whether to shrink the filesystems to reclaim free space from the filesystems backed up off the source system.

7. After you've verified the installation settings are to your liking, select option #0 to "Continue."

8. The last menu (thank goodness) with the heading "System Backup Installation and Settings" will be displayed. Select option #0 -- "Install with the Settings listed above." The cloning procedure will begin. Once completed, the F50 will take on the former identity and operation of the R40. Thus, you should make certain that both aren't on the network at the same time.

How Did You Do That?

At the heart of the cloning procedure is the initial command that begins the entire process -- mksysb -i. For those of you new to AIX, mksysb is the command used to back up the entire root volume group (rootvg), which contains the OS filesystems and related data. Additionally, the resulting backup tape is bootable, so it can be used to perform single-user maintenance on failed systems. Obviously, it is a great disaster recovery tool for your AIX servers. However, in our example, we use a very important flag -- the -i flag. This flag creates the /image.data and /bosinst.data files.

The image.data file will contain filesystem, logical volume (containers for the filesystem on AIX), and volume group (similar to Veritas VM disk groups) information for the rootvg. For example, in this file, you can specify:

• Physical partition sizes
• Sizes of logical volumes
• Filesystems
• Block sizes
• Whether filesystems should be shrunk on the new system
• Whether compression is enabled

From this file, the cloning installation will determine the layout of the volumes and filesystems on the target machine.

The bosinst.data file controls "how" the install will take place, such as:

• Installation method
• Whether the Trusted Computing Base will be installed
• Whether the install should be interactive or hands-off
• A customization script that will execute after the install is complete, similar to a Solaris JumpStart finish script
• Whether the installation program should attempt to configure the devices to have the same settings on the target system as the devices on the source system

Thus, there is potential for extensive customization of the cloning process.

You may be wondering how you can customize with this command if right after you type in mksysb -i, it creates the two files and immediately backs them up. If you want to tweak these files before the actual backup takes place, just execute mkszfile first. This command creates the two aforementioned files. After customizing these files to your liking, execute mksysb /dev/rmt0. In case you are wondering, the -i flag is simply performing mkszfile && mksysb.

Now I've explained how the OS filesystems, volumes, and data are cloned onto the target system, but I have not covered how it can do this onto a totally different platform, perhaps even having different peripheral devices. Here's how it works:

After the mksysb restore completes, the configuration manager program (cfgmgr -i) is run. This program scans the I/O bus for new devices, then configures them for use based on device configuration methods defined in the ODM. Whenever cfgmgr encounters a device for which the device driver software is not installed, it will output the device driver fileset names (software packages) that need to be installed to configure new devices (thanks to information in the PdAt and Config_Rules object classes in the ODM -- more on that in a future article). Now if we add the -i switch to this command, cfgmgr will attempt to install the needed device drivers itself, instead of just complaining about missing ones. Also, the clone installation sequence will use the devinstall command to install the proper kernel and platform architecture filesets based on the output of the bootinfo -T and bootinfo -z commands, respectively.

Cloning Tips and Tricks

What if you don't want to clone an entire machine, but just certain attributes of an AIX server? On AIX, device attributes are stored in the ODM repository. However, AIX's definition of devices encompasses more than just hardware devices. The operating system itself is considered a device, namely, sys0. Network routing can be defined and altered by manipulating the inet0 device. However, you can opt to simply use the route command to set these, then place them into /etc/rc.net for persistence across reboots -- using the latter is a personal preference of mine. Therefore, we can see that kernel parameters and routing information, among other things, can be cloned onto other machines the way hardware device attributes are cloned to a machine. The undocumented /usr/lpp/bosinst/rda command (which stands for "Recover Device Attributes") can accomplish this feat. It gathers information from the ODM and constructs a shell script that will make the necessary changes on other AIX systems. Therefore, if I wanted to create a portable attribute cloning script for my AIX environment on BoxA, I'd do the following as the root user on BoxA:

# /usr/lpp/bosinst/rda -rs clone

AIX offers other avenues for cloning machines, such as over the network with NIM (Network Install Manager -- AIX's equivalent of Solaris JumpStart, HP-UX Ignite-UX, or RedHat Linux KickStart). AIX even allows you to clone another system's root volume group onto a separate disk on your running system via the alt_disk_install command. Why is this cool? Let's say that I have AIX 4.3.3 on my machine, and I install an AIX 4.3.3 mksysb image onto another unused disk in my system. With this setup, I could boot from the other drive and apply patches and fixes to it to test them. If something goes flaky because of it, I can simply reboot off the original rootvg boot disk to get things back to normal. Other scenarios include having two different versions of the operating system on each disk or cloning your currently running root volume group over to another disk, all while the system is up and running. Consider how valuable this is when using fiber-connected drives at long distances from the host. (Does anyone want to try to "roll your own" EMC TimeFinder?) Possibilities abound with AIX's cloning features, and I hope that this article has stirred your interest in experimenting with some interesting configurations.

All this talk about an ODM repository brings up another issue -- AIX strays from UNIX tradition in some aspects. In particular, its use of a central database for device configuration instead of ASCII flat files has confused a number of UNIX admins. As a consultant, I've worked on several variants of UNIX and have always embraced the differences of each. More importantly, though, I've been able to compare and contrast various features of different UNIX variants to get a better understanding of the similarities and differences. Therefore, in future articles, I will go into some of the unique features of AIX to provide a better understanding about why they exist, how they work, and how they compare to paralleled functions of other UNIX variants. Perhaps, in the end, we can determine if these oddities provide added benefit and functionality, or just added confusion. See Listing 1 for an example file. Happy cloning!

For more information on cloning via mksysb or NIM (over the network), search on cloning at:

http://www.rs6000.ibm.com/cgi-bin/ds_form or

http://techsupport.services.ibm.com/rs6k/techbrowse/

Mark E. Dawson, Jr. currently works for Collective Technologies as a UNIX and Oracle systems consultant. He has more than five years of experience hacking around AIX, Linux, and Solaris kernel internals, and has been known to architect an Oracle/Sybase database or two. He can be contacted at: medawsonjr@yahoo.com.