Supported Methods of Duplicating an AIX System
Technote (FAQ)
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.
Why Duplicate A System?
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.
This can either be a mksysb backup of the rootvg from the source system to tape, DVD, or a file on a NIM server.
If the mksysb is going to be used to create a new machine, make sure to set 'recover devices' to NO when it is restored. This will insure that devices existing on the source machine aren't added to the ODM of the target machine.
2. Using the alt_disk_copy command.
If you have extra disks on your system, or have disks you would like to associate with one system, load a rootvg, then remove them and associate with a new system, this is a good way to copy the rootvg to them.
The basic command to do this would be:
# alt_disk_copy -BOd hdiskx
The -B option tells alt_disk_copy not to change the bootlist to this new copy of rootvg, the -O option will remove devices from your customized ODM database.
From the alt_disk_copy man page:
-O
Performs a device reset on the target altinst_rootvg. This causes
the alternate disk install to not retain any user-defined device
configurations. This flag is useful if the target disk or disks
become the rootvg of a different system (such as in the case of
logical partitioning or system disk swap).
When the disks containing this altinst_rootvg are moved to another host and then booted from, AIX will run cfgmgr and probe for any hardware, adding ODM information at that time.
3. Using alt_disk_mksysb to install a mksysb image on another disk.
Using this technique a mksysb image is first created, either to a file, on CD or DVD or tape.
Then that mksysb image is restored to unused disks in the current system using alt_disk_mksysb, again using the -O option to perform a device reset.
After this the disks could be removed and placed in a new system, or via fibre rezoned to a new system, and the rootvg booted up.
Advanced Techniques
1. Live Partition Mobility
Using the Live Partition Mobility feature of AIX you can migrate an AIX LPAR and applications from one LPAR to another while it is up and running. Please see the AIX Manual for further information:
http://publib.boulder.ibm.com/infocenter/aix/v6r1/topic/com.ibm.aix.baseadmn/doc/baseadmndita/lpm_overview.htm
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.
http://www.ibm.com/developerworks/aix/library/au-AIX_HA_SAN/index.html
Unsupported Methods
1. Using a bitwise copy of a rootvg disk to another disk.
This bitwise copy can be a one-time snapshot copy such as flashcopy, from one disk to another, or a continuously-updating copy method, such as Metro Mirror.
While these methods will give you an exact duplicate of the installed AIX operating system, the copy of the OS may not be bootable.
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.
Why don't these methods work?
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 usually the system will typically fail to boot with LED 554 (unknown boot disk).
Technote (FAQ)
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.
Why Duplicate A System?
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.
This can either be a mksysb backup of the rootvg from the source system to tape, DVD, or a file on a NIM server.
If the mksysb is going to be used to create a new machine, make sure to set 'recover devices' to NO when it is restored. This will insure that devices existing on the source machine aren't added to the ODM of the target machine.
2. Using the alt_disk_copy command.
If you have extra disks on your system, or have disks you would like to associate with one system, load a rootvg, then remove them and associate with a new system, this is a good way to copy the rootvg to them.
The basic command to do this would be:
# alt_disk_copy -BOd hdiskx
The -B option tells alt_disk_copy not to change the bootlist to this new copy of rootvg, the -O option will remove devices from your customized ODM database.
From the alt_disk_copy man page:
-O
Performs a device reset on the target altinst_rootvg. This causes
the alternate disk install to not retain any user-defined device
configurations. This flag is useful if the target disk or disks
become the rootvg of a different system (such as in the case of
logical partitioning or system disk swap).
When the disks containing this altinst_rootvg are moved to another host and then booted from, AIX will run cfgmgr and probe for any hardware, adding ODM information at that time.
3. Using alt_disk_mksysb to install a mksysb image on another disk.
Using this technique a mksysb image is first created, either to a file, on CD or DVD or tape.
Then that mksysb image is restored to unused disks in the current system using alt_disk_mksysb, again using the -O option to perform a device reset.
After this the disks could be removed and placed in a new system, or via fibre rezoned to a new system, and the rootvg booted up.
Advanced Techniques
1. Live Partition Mobility
Using the Live Partition Mobility feature of AIX you can migrate an AIX LPAR and applications from one LPAR to another while it is up and running. Please see the AIX Manual for further information:
http://publib.boulder.ibm.com/infocenter/aix/v6r1/topic/com.ibm.aix.baseadmn/doc/baseadmndita/lpm_overview.htm
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.
http://www.ibm.com/developerworks/aix/library/au-AIX_HA_SAN/index.html
Unsupported Methods
1. Using a bitwise copy of a rootvg disk to another disk.
This bitwise copy can be a one-time snapshot copy such as flashcopy, from one disk to another, or a continuously-updating copy method, such as Metro Mirror.
While these methods will give you an exact duplicate of the installed AIX operating system, the copy of the OS may not be bootable.
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.
Why don't these methods work?
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 usually the system will typically fail to boot with LED 554 (unknown boot disk).
No comments:
Post a Comment