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
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.
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
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
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
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
- 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
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
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
# /usr/lpp/bosinst/rda -rs clone
The resulting shell script is called "clone." You can open
and edit the script to make any modifications that you wish, then
execute the script on each of your other AIX boxes. Now, you have
identically configured machines. Yep, you guessed it. This same command
is also used during the mksysb cloning process. There are other
uses for this command that are documented in what I believe is the
best book on AIX ever written -- Andreas Siegert's AIX
Survival Guide. For anyone who wants to know more than just SMIT
(AIX's administrative GUI), this is definitely the book to get.
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:
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: firstname.lastname@example.org.