Using alt_disk_copy (see the Resources section) to clone your rootvg disks for ease of back-out when doing AIX® upgrades or applications upgrades that resided on the rootvg disks. In that article, I did not cover hardware migrations as this was out of scope. In this article, I discuss how this can be achieved. The man page on alt_disk_copy states (by using the 'O' option), "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."
In a nutshell, this means that any devices that have had their attributes changed, typically by the system administer, are reset to the default value(s). This could mean any changes to the following, but not restricted to:
- Ethernet cards—reset of IP addresses /hostname
- Fibre (SAN) cards—reset of any attributes changes, like fc_err_recov
- sys0—reset of any attributes changes, like maxuproc
- Reset of the diag hardware email notification list
The process of the migration or move using the cloned rootvg disk method is down to your operating requirements. The most common use is to clone a rootvg disk and insert it onto the new machine for a new base build. This process can be done with the source machine still running. Indeed, it is practical that once the cloned disk is across, you get that disk mirrored, then insert a new disk on the source, and re-mirror that one so you have no down time on the source machine.
However, in this demonstration, I will point out procedures one could use to migrate to new hardware. Taking fibre cards from the source machine to the new machine, as well as the SAN attached disks. As a general rule, there is no need to remove the Ethernet cards, as any new machine, should already have these present.
Review your existing configuration
When migrating to new hardware, review your inittab setting, comment out the services that you do not want to come up until the migration is complete. It is also advisable to take configuration listing of the current AIX machine, so any changes that are reset by the alt_disk_copy and be changed once the new system is brought up.
The following is not an exhaustive list of configuration listing you need to check and amend on the new system when migrating, but it is a good starting point:
- Listings of all VGs and their LV contents
- Listing of all the PVs
- lsattr -El output of all fibre and scsi cards
- For aio servers, on AIX 6 and 7, ioo -a
- For aio server, on 5.3 and below use: lsattr -El aio0
- Listings of Ethernet cards (including ether-channel if present)
- Take note of IPs and gateway addresses
- lscfg -vp output
- lsdev output (ie: lsdev -Cc disk)
In this demonstration, you can assume:
- alpha is the source host.
- bravo is the destination host.
On host alpha, make sure the rootvg is mirrored. In this demonstration, we can see that rootvg is not fully mirrored, /opt/db2_09_01, only has one copy. So you need to fix that before unmirroring rootvg.
# lsvg -l rootvg
rootvg:
LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
hd5 boot 1 2 2 closed/syncd N/A
hd6 paging 4 8 2 open/syncd N/A
hd8 jfs2log 1 2 2 open/syncd N/A
hd4 jfs2 8 16 2 open/syncd /
hd2 jfs2 36 72 2 open/syncd /usr
hd9var jfs2 3 6 2 open/syncd /var
hd3 jfs2 16 32 2 open/syncd /tmp
hd1 jfs2 8 16 2 open/syncd /home
hd10opt jfs2 6 12 2 open/syncd /opt
hd11admin jfs2 1 2 2 open/syncd /admin
lg_dumplv sysdump 8 16 1 open/syncd N/A
livedump jfs2 2 4 2 open/syncd /var/adm/ras/l
ivedump
fwdump jfs2 1 2 2 open/syncd /var/adm/ras/p
latform
fslv01 jfs2 8 8 1 open/syncd /opt/db2_09_01
loglv01 jfslog 1 2 2 open/syncd N/A
# mklvcopy fslv01 2
# syncvg -l fslv01
# lsvg -l rootvg
rootvg:
LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
hd5 boot 1 2 2 closed/syncd N/A
hd6 paging 4 8 2 open/syncd N/A
hd8 jfs2log 1 2 2 open/syncd N/A
hd4 jfs2 8 16 2 open/syncd /
hd2 jfs2 36 72 2 open/syncd /usr
hd9var jfs2 3 6 2 open/syncd /var
hd3 jfs2 16 32 2 open/syncd /tmp
hd1 jfs2 8 16 2 open/syncd /home
hd10opt jfs2 6 12 2 open/syncd /opt
hd11admin jfs2 1 2 2 open/syncd /admin
lg_dumplv sysdump 8 16 1 open/syncd N/A
livedump jfs2 2 4 2 open/syncd /var/adm/ras/l
ivedump
fwdump jfs2 1 2 2 open/syncd /var/adm/ras/p
latform
fslv01 jfs2 8 16 2 open/syncd /opt/db2_09_01
loglv01 jfslog 1 2 2 open/syncd N/A
Confirm your boot image is good and mirrored, if not alt_disk_copy will fail:
# lslv -m hd5
hd5:N/A
LP PP1 PV1 PP2 PV2 PP3 PV3
0001 0001 hdisk0 0001 hdisk1
Identify the disk to move
Before alt_disk is executed, it is good prudence to identify physically the disk that will be removed. Depending on how your disks are placed, use either the hot-swap smit utility or smit diag to identify the disk location using the menu selections:
smit diag
task selection
identify /attention indicator
Make sure you know which is hdisk0 and hdisk1. A useful tip here is to put a small sticker of each drive with their corresponding hdisk names, so you can be sure you do not remove the wrong disk. In this demonstration, we will initially be moving hdisk1 to the new hardware, so first locate hdisk1 location code, using:
# lscfg -vp |grep -w hdisk1
hdisk1 U787F.001.DPM0Y7F-P1-T10-L4-L0 16 Bit LVD SCSI Disk Drive (
18200 MB)
Now using smit diag, use the above hdisk1 location code to match up with the device location code you want to identify. Once the hdisk1 light comes on, label it, for reference.
- run bosboot
- unmirrorvg rootvg
- reducevg rootvg to remove hdisk1
# bosboot -a
# unmirrorvg rootvg hdisk1
0516-1246 rmlvcopy: If hd5 is the boot logical volume, please run 'chpv -c <disk
name>'
as root user to clear the boot record and avoid a potential boot
off an old boot image that may reside on the disk from which this
logical volume is moved/removed.
0516-1804 chvg: The quorum change takes effect immediately.
0516-1144 unmirrorvg: rootvg successfully unmirrored, user should perform
bosboot of system to reinitialize boot records. Then, user must modify
bootlist to just include: hdisk0.
# reducevg rootvg hdisk1
# lspv
hdisk0 00c23bed7c1b3d4b rootvg active
hdisk1 00c23bedf2976238 None
hdisk2 00525c6a888e32cd apps_vg active
Now we can clone hdisk1 from the current AIX in rootvg which is hdisk0. The format for the alt_disk_copy is:
alt_disk_copy -Od hdisk1
- O, described earlier, removes all user defined ODM entries.
- d is the destination disk when the cloned rootvg disk is to go; in this example, it is hdisk1.
You can also specify bootlist options, but I prefer to control this myself as part of the checklist during the migration. Listing 1 below contains the full output from running the alt_disk_copy command.
Listing. 1 alt_disk output
# alt_disk_copy -Od hdisk1
Calling mkszfile to create new /image.data file.
Checking disk sizes.
Creating cloned rootvg volume group and associated logical volumes.
Creating logical volume alt_hd5
Creating logical volume alt_hd6
Creating logical volume alt_hd8
Creating logical volume alt_hd4
Creating logical volume alt_hd2
Creating logical volume alt_hd9var
Creating logical volume alt_hd3
Creating logical volume alt_hd1
Creating logical volume alt_hd10opt
Creating logical volume alt_hd11admin
Creating logical volume alt_lg_dumplv
Creating logical volume alt_livedump
Creating logical volume alt_fwdump
Creating logical volume alt_fslv01
Creating logical volume alt_loglv01
Creating logical volume alt_lv00
Creating /alt_inst/ file system.
/alt_inst filesystem not converted.
Small inode extents are already enabled.
Creating /alt_inst/admin file system.
/alt_inst/admin filesystem not converted.
Small inode extents are already enabled.
Creating /alt_inst/home file system.
/alt_inst/home filesystem not converted.
Small inode extents are already enabled.
Creating /alt_inst/opt file system.
/alt_inst/opt filesystem not converted.
Small inode extents are already enabled.
Creating /alt_inst/opt/db2_09_01 file system.
/alt_inst/opt/db2_09_01 filesystem not converted.
Small inode extents are already enabled.
Creating /alt_inst/storix file system.
Creating /alt_inst/tmp file system.
/alt_inst/tmp filesystem not converted.
Small inode extents are already enabled.
Creating /alt_inst/usr file system.
/alt_inst/usr filesystem not converted.
Small inode extents are already enabled.
Creating /alt_inst/var file system.
/alt_inst/var filesystem not converted.
Small inode extents are already enabled.
Creating /alt_inst/var/adm/ras/livedump file system.
/alt_inst/var/adm/ras/livedump filesystem not converted.
Small inode extents are already enabled.
Creating /alt_inst/var/adm/ras/platform file system.
/alt_inst/var/adm/ras/platform filesystem not converted.
Small inode extents are already enabled.
Generating a list of files
for backup and restore into the alternate file system...
Backing-up the rootvg files and restoring them to the
alternate file system...
Modifying ODM on cloned disk.
Building boot image on cloned disk.
Resetting all device attributes.
NOTE: The first boot from altinst_rootvg will prompt to define the new
system console.
Resetting all device attributes.
NOTE: The first boot from altinst_rootvg will prompt to define the new
system console.
forced unmount of /alt_inst/var/adm/ras/platform
forced unmount of /alt_inst/var/adm/ras/platform
forced unmount of /alt_inst/var/adm/ras/platform
forced unmount of /alt_inst/var/adm/ras/livedump
forced unmount of /alt_inst/var/adm/ras/livedump
forced unmount of /alt_inst/var
forced unmount of /alt_inst/var
forced unmount of /alt_inst/usr
forced unmount of /alt_inst/usr
forced unmount of /alt_inst/tmp
forced unmount of /alt_inst/tmp
forced unmount of /alt_inst/storix
forced unmount of /alt_inst/opt/db2_09_01
forced unmount of /alt_inst/opt/db2_09_01
forced unmount of /alt_inst/opt
forced unmount of /alt_inst/opt
forced unmount of /alt_inst/home
forced unmount of /alt_inst/home
forced unmount of /alt_inst/admin
forced unmount of /alt_inst/admin
forced unmount of /alt_inst
forced unmount of /alt_inst
Changing logical volume names in volume group descriptor area.
Fixing LV control blocks...
Fixing file system superblocks...
Bootlist is set to the boot disk: hdisk1 blv=hd5
# lspv
hdisk0 00c23bed7c1b3d4b rootvg active
hdisk1 00c23bedf2976238 altinst_rootvg
After executing alt_disk_copy, unless otherwise specified, the default action is to set its bootlist to the disk alt_disk it resides on; in this case, it is hdisk1. We need to err to caution and make sure host alpha will still reboot back to hdisk0 in case we have to backout of the migration. So change the bootlist to hdisk0:
# bootlist -m normal hdisk0
Then shut down host alpha.
At this point, we could have kept host alpha up and dynamically remove the disk by using:
# rmdev -dl hdisk1
However, eventually we will need to shut host alpha down to remove the remaining rootvg hdisk. So we might as well shut it down now.
In this scenario, we are moving the current hardware cards from host alpha and inserting them into host bravo. Host alpha and bravo are currently down.
- Remove the network cable and the SAN fibre cables, if present, along with the fibre cards and insert these cards on the host bravo; then plug the cables in.
- On host bravo remove the existing, if present, internal boot disks as we will be replacing these from host alpha.
- On host alpha remove, hdisk1 and insert it into host bravo in the location that was previously populated with the boot disks.
- Bring up host bravo; upon boot up, go into the SMS menu.
When host bravo comes, it will display the firmware/SMS menu prompts. Hit 1 to enter SMS menu, as shown below in Figure 1.
Figure 1. SMS
Go to the boot order list and select the disk to boot up on. There should only be one disk to boot up. Figure 2 shows the newly cloned disk to boot up on.
Figure 2. SMS boot list
Upon booting off that disk, the AIX kernel starts to load as shown in Figure 3. The disk comes up and loads AIX.
Figure 3. Booting up
You are then prompted to define the system console, select 1 for this console, as shown in Figure 4. The console definition has been reset, because it is a ODM user defined attribute.
Figure 4. Identify new console
Once AIX is booted up, log in and check your disk:
# lspv
hdisk0 00c23bedf2976238 rootvg active
Notice that the formally named hdisk1 on host alpha is now hdisk0 on host bravo. Change the bootlist to boot of this disk, until the migration is complete:
# bootlist -m normal hdisk0
Configure the network card to the IP that was used on host alpha and the card speed, if required. Confirm you are connected onto the network, test to ensure that you can ping outside your gateway, and ensure you can connect to the DNS via any of the following commands:
nslookup
dig
host
Confirm that you can connect to the host bravo via telnet/ssh from a remote session. You may have to start manually ssh on host bravo as this may not be running:
# startsrc -s sshd
Bring in the other rootvg disk
If all is OK at this point, we can bring in the other rootvg disk from host alpha:
- Remove the last boot disk (hdisk0) from host alpha.
- Insert the disk in host bravo; this disk is now hdisk1.
- Run cfgmgr to discover the disk.
We are not mirroring the disk just yet. First, we need to make sure we get all the SAN disks discovered. If we have issues with this, we can take the newly insert disk back to the original box in case we need to back out of the migration.
Review hardware attributes and bring in the VGs
On host bravo, check for any changes that may need to be done from the listings taken from the output of the aio, sys0, scsi/fibre card(s). Adjust these setting, either via smit or the chdev command.
Discover the WWNs for the fibre cards. This is obtained looking at the output from the lscfg -vp command and searching for the SAN cards fcs0, fcs1, etc. Once obtained, use these to re-zone in the SAN disks from the switch, then import the VGs. If you have more than one SAN VG across different switches, then I recommend only leaving in the cable for the switch that holds one of the VGs. Pull the disks in using cfgmr; then import that VG. Once imported, plug in the other fibre cable and re-run cfgmgr and import that VG. The reason for this is if you do not, all the disks will come down the fibre paths. When you import the VGs, all the disks will be imported onto that one VG, which is probably not what you want. (You do not get this issue with scsi raid controllers that have more than one VG).
If you have problems with importvg, be sure to check out the cables attached. You may have to run varyonvg afterwards, as AIX does not automatically varyonvg if it gets issues with the importvg.
Next, mount the file-systems.
# mount -a
Check to ensure that all file-systems are mounted and all LVs are open.
# lsvg -l <vg name>
Uncomment the changes that was made to the inittab.
Refresh iniitab, so it is re-read.
# init q
Now start the applications up and test.
If all looks good at this point and the sanity checks are good, mirror up the other disk. You need to use the force option when bringing it into rootvg.
# extendvg -f rootvg hdisk1
# mirrorvg rootvg hdisk1
Oh no, it's all gone terribly wrong!
If the migration or move fails, remove the second (boot) disk from host bravo. Remember this should have not been put into rootvg on host bravo until all the applications are tested OK. So this disk still holds the ODM setting from host alpha, so you are good to go for a back-out process. Using the procedures described in the article about moving the cards/cables, simply do it in reverse.
In some situations, it maybe the case the disk will be shown with the alt_disk tag still associated with it. Simply remove this tag before bringing it into rootvg and mirroring up.
# alt_rootvg_op -X altinst_rootvg
I have highlighted just one method of a hardware migration. Though this has not been a step-by-step guide, it does provide one way you can approach a migration. There are different variations you can employ to do a hardware migration or move using alt_disk_copy. The alt_disk_copy utility is a good tool to use when you wish to migrate to new hardware, and the machines are located in the same location room.
![Join Us on Facebook](https://2.bp.blogspot.com/-7_3aMhrvLq4/UTtUB9H5ZyI/AAAAAAAABcM/JjZGcP7r3_I/s1600/fbb.png")
![Follow us on Twitter](https://2.bp.blogspot.com/-VXfOkCT43uI/UTtUEItlzyI/AAAAAAAABck/cvROEjW1Vx8/s1600/tww.png")