AIX multibos mksysb migrationI’ve written about multibos before, here and here. But recently I started experimenting with multibos mksysb migration. A customer asked me how this worked and apart from a high-level view I wasn’t able to provide any real world experience, so I thought I’d give it a try. What follows is just a ‘brain dump’ from my quick test.
First of all this isn’t really a migration. It just simply populates a second instance of AIX with a higher-version. It doesn’t really migrate (or merge) your existing configuration into the second instance. So I’m not sure how useful this feature really is right now.
Starting with 5.3 TL9 you can add a 6.1 TL2 (or above) instance. This is done with the new –M flag. You must be running with the 64bit kernel.
So in my lab environment I have two AIX LPARs. One is running AIX 6.1 and the other running AIX 7.1.
First I take a mksysb (with the –M flag) of the AIX 7.1 system to a file. This file will be called by multibos to populate the second instance.
aix7[/] > mksysb -Mie /data/aix7-mksysb
Creating information file (/image.data) for rootvg.
Creating list of files to back up.
Backing up 71643 files.....
71643 of 71643 files (100%) 0512-038 mksysb: Backup Completed Successfully.
aix7[/] > ls -ltr /data total 4276112 drwxr-xr-x 2 root system 256 Feb 21 20:59 lost+found -rw-r--r-- 1 root system 2189363200 Feb 21 21:06 aix7-mksysb
I copied this file over to my AIX 6.1 system. This was the system that was to be ‘migrated’. The next step was to perform a preview of the multibos operation.
root@aix6 /# multibos -sXp -M /data/aix7-mksysb Initializing multibos methods ... Initializing log /etc Gathering system information ...
+--- Preview +--- Verifying operation parameters ... Validating install images location ./aix7-mksysb Processing preview information ...
ACTIVE LV: hd4 STANDBY LV: bos_hd4 TYPE: jfs2 ACTIVE FS: / STANDBY FS: /bos_inst ACTION: Setup STATE: mounted
ACTIVE LV: hd2 STANDBY LV: bos_hd2 TYPE: jfs2 ACTIVE FS: /usr STANDBY FS: /bos_inst/usr ACTION: Setup STATE: mounted
ACTIVE LV: hd9var STANDBY LV: bos_hd9var TYPE: jfs2 ACTIVE FS: /var STANDBY FS: /bos_inst/var ACTION: Setup STATE: mounted
ACTIVE LV: hd10opt STANDBY LV: bos_hd10opt TYPE: jfs2 ACTIVE FS: /opt STANDBY FS: /bos_inst/opt ACTION: Setup STATE: mounted
ACTIVE LV: hd5 STANDBY LV: bos_hd5 TYPE: boot ACTIVE FS: None STANDBY FS: None ACTION: Setup STATE: closed
ACTIVE LV: hd8 STANDBY LV: bos_hd8 TYPE: jfs2log ACTIVE FS: None STANDBY FS: None ACTION: Setup STATE: open
Log file is
/etc Return Status = SUCCESS
With a successful preview out of the way, I initiated the real multibos operation.
# multibos -sX -M /data/aix7-mksysb
Gathering system information ...
+--- Setup Operation +--- Verifying operation parameters ... Validating install images location ./aix7-mksysb New volume on /data/aix7-mksysb: Cluster size is 51200 bytes (100 blocks). The volume number is 1. The backup date is: Mon Feb 21 21:05:39 CST 2011 Files are backed up by name. The user is root. x 13007 ./image.data x 168589 ./tm The total size is 181596 bytes. The number of restored files is 2.
+--- Logical Volumes +--- Creating standby BOS logical volume bos_hd5 Creating standby BOS logical volume bos_hd4 Creating standby BOS logical volume bos_hd2 Creating standby BOS logical volume bos_hd9var Creating standby BOS logical volume bos_hd10opt Creating standby BOS logical volume bos_hd8
+--- File Systems +--- Creating all standby BOS file systems ... Creating standby BOS file system /bos_inst on logical volume bos_hd4 Creating standby BOS file system /bos_inst/usr on logical volume bos_hd2 Creating standby BOS file system /bos_inst/var on logical volume bos_hd9var Creating standby BOS file system /bos_inst/opt on logical volume bos_hd10opt
+--- Mount Processing +--- Mounting all standby BOS file systems ... Mounting /bos_inst Mounting /bos_inst/usr Mounting /bos_inst/var Mounting /bos_inst/opt
+--- BOS Files +--- Including files for file system / Including files for file system /usr Including files for file system /var Including files for file system /opt
Copying files using backup/restore utilities ... New volume on /data/aix7-mksysb: Cluster size is 51200 bytes (100 blocks). The volume number is 1. The backup date is: Mon Feb 21 21:05:39 CST 2011 Files are backed up by name. The user is root. x 6086 ./bosinst.data x 11 ./tm x 13007 ./image.data x 168589 ./tm x 0 ./ x 47 ./.profile x 63 ./.rhosts x 13192 ./.sh_history x 0 ./.ssh x 1647 ./.s x 0 ./.topasrecrc x 0 ./.t x 141722 ./.t x 0 ./.t x 108 ./.vi_history x 0 ./admin x 0 ./audit x 8 ./bin x 0 ./cdat x 59 ./cdat/cdat.xml x 0 ./cg x 0 ./cgps x 0 ./dev x 0 ./dev/.SRC-unix x 0 ./dev/IPL_rootvg x 0 ./de x 0 ./dev/__vg10 x 0 ./dev/audit .....BLAH..... x ./dev/zero Creating standby BOS boot image on boot logical volume bos_hd5 254+0 records in. 254+0 records out. 179+1 records in. 177+1 records out. saving to '/dev/bos_hd5' 44 CuDv objects to be saved 130 CuAt objects to be saved 21 CuDep objects to be saved 7 CuVPD objects to be saved 351 CuDvDr objects to be saved 2 CuPath objects to be saved 0 CuPathAt objects to be saved 0 CuData objects to be saved Number of bytes of data to save = 18716 Compressing data Compressed data size is = 6393 bi_start = 0x400 bi_size = 0x1677200 bd_size = 0x1657200 ram FS start = 0x8c3570 ram FS size = 0xd93abe sba_start = 0x1657600 sba_size = 0x20000 sbd_size = 0x0 Checking boot image size: new save base byte cnt = 0x18fd Wrote 6397 bytes Successful completion
+--- Mount Processing +--- Unmounting all standby BOS file systems ... Unmounting /bos_inst/opt Unmounting /bos_inst/var Unmounting /bos_inst/usr Unmounting /bos_inst
+--- Bootlist Processing +--- Verifying operation parameters ... Setting bootlist to logical volume bos_hd5 on hdisk0. ATTENTION: firmware recovery string for standby BLV (bos_hd5): boot
/vde ATTENTION: firmware recovery string for standby BLV (bos_hd5): boot
/vde ATTENTION: firmware recovery string for active BLV (hd5): boot
/vde ATTENTION: firmware recovery string for active BLV (hd5): boot
/vde
Log file is
/etc Return Status = SUCCESS
Now that the second instance had been created, I thought I’d try to start a multibos shell and access the AIX 7.1 environment. I didn’t think this would work but I tried my luck anyway!
root@aix6 /# multibos -S Initializing multibos methods ... Initializing log
/etc Gathering system information ...
+--- Multibos Shell Operation +--- Verifying operation parameters ...
+--- Mount Processing +--- Mounting all standby BOS file systems ... Mounting /bos_inst Mounting /bos_inst/usr Mounting /bos_inst/var Mounting /bos_inst/opt
+--- Multibos Root Shell +--- Starting multibos root shell ... multibos: 0565-110 Cannot start multibos shell due to incompatible levels of active and standby BOS.
+--- Mount Processing +--- Unmounting all standby BOS file systems ... Unmounting /bos_inst/opt Unmounting /bos_inst/var Unmounting /bos_inst/usr Unmounting /bos_inst
Log file is /etc Return Status: FAILURE
Upon checking my bootlist output, I noticed (as expected) that the list now contained two extra entries for bos_hd5. These were the boot logical volume entries for the second instance. If I was to boot from this LV I’d be booting into AIX 7.1. Cool.
root@aix6 /# bootlist -m normal -o hdisk0 blv=bos_hd5 hdisk0 blv=bos_hd5 hdisk0 blv=hd5 hdisk0 blv=hd5
So at this point, I’d created a second instance of AIX running 7.1. My current version of (running) AIX was AIX 6.1. All I had to do now was reboot the LPAR and let it restart as an AIX 7.1 system.
root@aix6 /# oslevel -s 6100-01-05-0920
root@aix6 / # shutdown –Fr
The LPAR rebooted successfully and I found I was now running AIX 7.1, just as I’d hoped.
aix6[/] > oslevel -s 7100-00-01-1037
If I wanted to go back to AIX 6.1, I would change my bootlist setting again and restart the LPAR.
aix6[/] > bootlist -m normal -o hdisk0 blv=bos_hd5 pathid=0 hdisk0 blv=bos_hd5 pathid=1 hdisk0 blv=hd5 pathid=0 hdisk0 blv=hd5 pathid=1
aix6[/] > bootlist -m normal hdisk0 blv=hd5 pathid=0 hdisk0 blv=hd5 pathid=1 hdisk0 blv=bos_hd5 pathid=0 hdisk0 blv=bos_hd5 pathid=1 aix6[/] > bootlist -m normal -o hdisk0 blv=hd5 pathid=0 hdisk0 blv=hd5 pathid=1 hdisk0 blv=bos_hd5 pathid=0 hdisk0 blv=bos_hd5 pathid=1
aix6[/] > shutdown –Fr
root@aix6 /# oslevel -s 6100-01-05-0920
Now that I’ve actually tried this method of migration, I’m not sure I’d actually use it in its current form.
Although the migration keeps my hostname and IP address, the file systems are not shared between instances. Most of the target systems configuration is not retained. For example, any user accounts I create on my AIX 6.1 system would also need to be created on the existing AIX.7.1 system which I used to create the AIX 7.1 mksysb image. It reminds me a little of a preservation install.
More information on multibos:
http
|
Hi Somesh, If you recorded the bootlist output prior to rebooting then you can use this information to determine which disk to boot from in the openfirmware prompt. For example: # bootlist -m normal -ov 'ibm,max-boot-devices' = 0x5 NVRAM variable: (boot-device=/vdevice/v-scsi@30000002/disk@8100000000000000:2 /vdevice/v-scsi@30000003/disk@8100000000000000:2) Path name: (/vdevice/v-scsi@30000002/disk@8100000000000000:2) match_specific_info: ut=disk/vscsi/vdisk hdisk0 blv=hd5 pathid=0 Path name: (/vdevice/v-scsi@30000003/disk@8100000000000000:2) match_specific_info: ut=disk/vscsi/vdisk hdisk0 blv=hd5 pathid=1 At the openfirmware prompt: 0> boot /vdevice/v scsi@30000002/disk@8100000000000000:2 | Where: /vdevice - Virtual I/O Bus /v-scsi@30000004 - Virtual I/O SCSI Adapter /disk@8100000000000000:4 - Virtual I/O SCSI Disk Device This is documented in the following article: http://www.ibmsystemsmag.com/aix/trends/aix/AIX-Updates-With-Multibos/ Or you could simply boot into SMS and select the alternate boot disk partition. Good luck! Cheers. Chris
Hi Thanks for the document I tried this way and when i rebooted with multibos boot device its not booting up Can you please how can i boot the server with an old boot device . Error code :e14d led code Can you please help This is what the error when i tried to boot from raritan console : boot Unable to use memory at load-base Data stack pointer = c10ff8 000000c10ff0: 00 00 00 00 00 00 00 10 ff ff ff ff ff ff ff fe :................: 000000c11000: 00 00 00 00 de ad be ef 00 00 00 00 00 00 00 00 :................: 000000c11010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 :................: 000000c11020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 :................: Call History ------------ throw - c3ba04 $abort - c47c80 map-load-addr - c8a648 $load - c8a748 (poplocals) - c3d040 (load) - c8ab08 boot|load - c8ba18 boot - c8c1f0 evaluate - c4d1c0 ^c17100 - c17100 invalid pointer - 4 invalid pointer - 4 quit - c4dadc quit - c4d698 My Fix Pt Regs: 00 0000011000000000 9000000000003002 00000000deadbeef 0000000000c47c7c 04 0000000000000021 0000000000c8a621 0000000000c11f58 0000000000c03008 08 0000000100000000 00000000fd677f5f 0000000000c8a744 0000000000000000 0c 0000000000009ec8 0000000000000000 0000000000000000 0000000000000000 10 0000000000ee5170 0000000000ee5120 0000000000c47c74 0000000000c47c80 14 fffffffffffffffe 0000000000004000 0000000000000000 0000000000000000 18 0000000000c13000 0000000000c38000 0000000000c14fc0 0000000000c16fc0 1c 0000000000c20000 0000000000c43338 0000000000c11f90 0000000000c10ff8 Special Regs: %IV: 00000900 %CR: 48808044 %XER: 20000000 %DSISR: 00000000 %SRR0: 0000000000c43160 %SRR1: 900000000000b002 %LR: 0000000000c3f73c %CTR: 0000000000000000 %DAR: 0000000000000000 Note: SRR0, SRR1, R0-R2 may have been altered by a dec-int. ok 0 > boot Unable to use memory at load-base Data stack pointer = c10ff8 000000c10ff0: 00 00 00 00 00 00 00 10 ff ff ff ff ff ff ff fe :................: 000000c11000: 00 00 00 00 de ad be ef 00 00 00 00 00 00 00 00 :................: 000000c11010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 :................: 000000c11020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 :................: Call History ------------ throw - c3ba04 $abort - c47c80 map-load-addr - c8a648 $load - c8a748 (poplocals) - c3d040 (load) - c8ab08 boot|load - c8ba18 boot - c8c1f0 evaluate - c4d1c0 ^c17100 - c17100 invalid pointer - 4 invalid pointer - 4 quit - c4dadc quit - c4d698 My Fix Pt Regs: 00 0000011000000000 9000000000003002 00000000deadbeef 0000000000c47c7c 04 0000000000000021 0000000000c8a621 0000000000c11f58 0000000000c03008 08 0000000100000000 00000000fd677f5f 0000000000c8a744 0000000000000000 0c 0000000000009ec8 0000000000000000 0000000000000000 0000000000000000 10 0000000000ee51c0 0000000000ee5170 0000000000c47c74 0000000000c47c80 14 fffffffffffffffe 0000000000004000 0000000000000000 0000000000000000 18 0000000000c13000 0000000000c38000 0000000000c14fc0 0000000000c16fc0 1c 0000000000c20000 0000000000c43338 0000000000c11f90 0000000000c10ff8 Special Regs: %IV: 00000900 %CR: 48808044 %XER: 20000000 %DSISR: 00000000 %SRR0: 0000000000c3cf44 %SRR1: 900000000000b002 %LR: 0000000000c3f73c %CTR: 0000000000000000 %DAR: 0000000000000000 Note: SRR0, SRR1, R0-R2 may have been altered by a dec-int. ok Thanks Somesh Chourey
Fraser, Yes that would be a logical way to use it. Although I can't help but feel like I've just jumped through several hoops to do something I could have done with NIM alone, in a lot less steps. Perhaps this would be useful if you did not have access to a NIM server at a remote site but you had one at your local site. You could do the nimadm mksysb migrate at the local site, then ftp the mksysb image over to the remote site and use multibos to "migrate" the remote LPAR to the higher-level of AIX. I guess one advantage is you don't need a spare disk with the multibos method as opposed to nimadm. Food for thought either way.
Do you think it would work if you took a mksysb image of your 6.1 system then used nimadm to upgrade it to 7.1 and use that image to restore to your multibos standby image. This way you would keep all your users etc. howerver the -M flag might prevent that. Fraser