Edit: Some links no longer work.
Originally posted December 1, 2015 on AIXchange
If you’re tasked with migrating, duplicating or cloning your system from old to new hardware, how do you go about it?
If the system isn’t too old, and your source systems are virtualized, you may be able to perform a live partition mobility operation. That process is non-intrusive enough that your users may not even realize there’s been a migration (although hopefully they’ll notice that things are running much faster on the new hardware).
Assuming the source system isn’t virtualized or is using internal disks, perhaps a fibre card is available. That way you could allocate some new LUNs to the source system, copy your rootvg data to them, and then swing the LUNs over to your destination. This method works — provided you do it correctly.
This technote covers some things to look for in IBM’s “Supported Methods of Duplicating an AIX System”:
Question: I would like to move, duplicate or clone an AIX system onto another partition or hardware. How can I accomplish this?
Answer: This document describes the supported methods of duplicating, or cloning, an AIX instance to create new systems based on an existing one. It also describes methods known to us that are not supported and will not work.
Q: Why Duplicate A System?
A: Duplicating an installed and configured AIX system has some advantages over installing AIX from scratch, and can be a faster way to get a new LPAR or system up and running.
Using this method customized configuration files, installation of additional AIX filesets, application configurations and tuning parameters can be set up once and then installed on another system or partition.
Supported Methods
1. Cloning a system via mksysb backup from one system and restore to new system.
2. Using the alt_disk_copy command.
3. Using alt_disk_mksysb to install a mksysb image on another disk.
Advanced Techniques
1. Live Partition Mobility
2. Higher Availability Using SAN Services
There are methods not described here, which have been documented by DeveloperWorks. Please refer to the document “AIX higher availability using SAN services” for details.
Non-Preferred Methods
There are other methods that in may not produce a bootable system under some scenarios. When used in a virtual environment or according to the IBM DeveloperWorks document mentioned above, they may be used to replicate or move a rootvg. However if used with directly attached disks (either internal or SAN-based) they may not work.
Some of these methods are:
1. Using a bitwise copy of a rootvg disk to another disk.
2. Removing the rootvg disks from one system and inserting into another.
This also applies to re-zoning SAN disks that contain the rootvg so another host can see them and attempt to boot from them.
Q: Why don’t these methods work?
A: The reason for this is there are many objects in an AIX system that are unique to it; Hardware location codes, World-Wide Port Names, partition identifiers, and Vital Product Data (VPD) to name a few. Most of these objects or identifiers are stored in the ODM and used by AIX commands.
If a disk containing the AIX rootvg in one system is copied bit-for-bit (or removed), then inserted in another system, the firmware in the second system will describe an entirely different device tree than the AIX ODM expects to find, because it is operating on different hardware. Devices that were previously seen will show missing or removed, and the system may fail to boot with LED 554 (unknown boot disk).
Feel free to share your own migration practices in comments.