wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== AIX:NIM alternate disk migration ======

AIX migration: it's an upgrade of AIX OS to a new level of AIX (Ex: 5.3 to 6.1)

With a NIM server it's possible to migrate a running AIX server, and activate the new OS level with only one reboot.
  

===== NIM Alternate disk migration requisites =====

  * The target client must be a registered with the master as a standalone NIM client. The NIM master must be able to execute remote commands on the client using the **rshd protocol**.
    * rlogin enable for root user on the target  # chuser rlogin=true root
    * create a file $HOME/.rhosts on the target with permissions 600, containing hostname of NIM master, as solved by target host (Ex: nimsrv.dom.eu)
    * Activate Rcommand in the /etc/inetd.conf <code>
shell   stream  tcp6    nowait  root    /usr/sbin/rshd  rshd 
login   stream  tcp6    nowait  root    /usr/sbin/rlogind       rlogind 
exec    stream  tcp6    nowait  root    /usr/sbin/rexecd        rexecd 
</code>
    * And execute : refresh -s inetd
    * Test a connection without password: Ex: rsh labotest ls
    * In case of trouble, check /etc/hosts.equiv file

  * The SPOT that you plan to use must contain the following packages:<code>bos.alt_disk_install.rte</code>
  * On the target enable push from master NIM <code>nimclient -p</code>
  * Change TZ variable in /etc/environment by commenting out the old value and adding a new line with: <code> TZ=Europe/Belgium </code>
  * The target machine must have a new disk free of data <code>
[root@labotest:/root/]# lspv
hdisk0          00c579f0d914b866                    rootvg          active
hdisk1          none                                None            
</code>
  * In case of TCB enable, you have to use a **disk cache VG** on the master, with enough space to contain a copy of the target rootvg without special LV. Check the state with: <code> odmget -q attribute="TCB_STATE" PdAt | grep tcb </code>
  * The nimadm command is not supported with the multibos command when there is a bos_hd5 logical volume.

**Be carefull:** If you have other applicative filesystems on rootvg, like /oracle, and the application is modifying files during migration, then you have to resynchronize it after the Reboot on new AIX level.
You can mount the old filesystems with : 
  # alt_rootvg_op -W -d hdisk0 ,and at the end put it on sleep again: 
  # alt_rootvg_op -S 

  * NIM master bos.alt_disk_install.rte installed package must be exactly at same level as into the spot
<code>
[root@nimsrv]/root# /usr/sbin/nim -o lslpp -a lslpp_flags=Lc -a filesets=bos.alt_disk_install.rte spot_aix6100-06 
bos.alt_disk_install:bos.alt_disk_install.rte:6.1.6.0: : :C: :Alternate Disk Installation Runtime : : : : : : :0:0:/:1036
[root@nimsrv]/root# /usr/bin/lslpp -Lc bos.alt_disk_install.rte
bos.alt_disk_install:bos.alt_disk_install.rte:6.1.6.1: : :C:F:Alternate Disk Installation Runtime: : : : : : :0:0:/:1048
</code>

===== Alternate disk migration =====

**On the NIM server:**
<code>
# smitty
--> Software Installation and Maintenance
--> Alternate Disk Installation
--> NIM Alternate Disk Migration
--> Perform NIM Alternate Disk Migration
</code>

<code>
                                                           Perform NIM Alternate Disk Migration

Type or select values in entry fields.
Press Enter AFTER making all desired changes.
  
                                                        [Entry Fields]
* Target NIM Client                                  [labotest]                                                                                           +
* NIM LPP_SOURCE resource                            [aix6100-04]                                                                                      +
* NIM SPOT resource                                  [spot_aix6100-04]                                                                                 +
* Target Disk(s) to install                          [hdisk1]
  DISK CACHE volume group name                       [nimvg]     ==> only if TCB enable                                                                +
  
  NIM IMAGE_DATA resource                            []                                                                                                +
  NIM BOSINST_DATA resource                          []                                                                                                +
  NIM EXCLUDE_FILES resource                         []                                                                                                +
  NIM INSTALLP_BUNDLE resource                       []                                                                                                +
  NIM PRE-MIGRATION SCRIPT resource                  []                                                                                                +
  NIM POST-MIGRATION SCRIPT resource                 []                                                                                                +
  
  Phase to execute                                   [all]                                                                                             +
  NFS mounting options                               []
  Set Client bootlist to alternate disk?              yes                                                                                              +
  Reboot NIM Client when complete?                    no                                                                                               +
  Verbose output?                                     no                                                                                               +
  Debug output?                                       no                                                                                               +
  
  ACCEPT new license agreements?                      yes                                                                                              +
</code>

Or with command line:
<cli prompt='#'>
# /usr/sbin/nimadm -H -c labotest -l aix6100-04 -s spot_aix6100-04 -d hdisk1 -Y
</cli>

New option in AIX 7.3.2 add **-A** timestamps per phase
Output:
<code>
Initializing the NIM master.
Initializing NIM client labotest.
Verifying alt_disk_migration eligibility.
Initializing log: /var/adm/ras/alt_mig/labotest_alt_mig.log
Starting Alternate Disk Migration.

+-----------------------------------------------------------------------------+
Executing nimadm phase 1.
+-----------------------------------------------------------------------------+
Cloning altinst_rootvg on client, Phase 1.
Client alt_disk_install command: alt_disk_copy -j -B -M 6.1 -P1 -d "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_fslv00.
Creating logical volume alt_hd7.
Creating /alt_inst/ file system.
Creating /alt_inst/admin file system.
Creating /alt_inst/audit file system.
Creating /alt_inst/home file system.
Creating /alt_inst/opt file system.
Creating /alt_inst/root file system.
Creating /alt_inst/tmp file system.
Creating /alt_inst/trace file system.
Creating /alt_inst/usr file system.
Generating a list of files
for backup and restore into the alternate file system...
Phase 1 complete.

+-----------------------------------------------------------------------------+
Executing nimadm phase 2.
+-----------------------------------------------------------------------------+
Creating nimadm cache file systems on volume group nimvg.
Checking for initial required migration space.
Creating cache file system /labotest_alt/alt_inst
Creating cache file system /labotest_alt/alt_inst/admin
Creating cache file system /labotest_alt/alt_inst/audit
Creating cache file system /labotest_alt/alt_inst/home
Creating cache file system /labotest_alt/alt_inst/opt
Creating cache file system /labotest_alt/alt_inst/root
Creating cache file system /labotest_alt/alt_inst/tmp
Creating cache file system /labotest_alt/alt_inst/trace
Creating cache file system /labotest_alt/alt_inst/usr

+-----------------------------------------------------------------------------+
Executing nimadm phase 3.
+-----------------------------------------------------------------------------+
Syncing client data to cache ...
.........................

SUCCESSES
---------
  Filesets listed in this section passed pre-commit verification
  and will be committed.

  Selected Filesets
  -----------------
  X11.compat.lib.X11R6_motif 6.1.4.1          # AIXwindows X11R6 Motif 1.2 &...

  << End of Success Section >>

+-----------------------------------------------------------------------------+
                          Committing Software...
+-----------------------------------------------------------------------------+

installp: COMMITTING software for:
        X11.compat.lib.X11R6_motif 6.1.4.1

Finished processing all filesets.  (Total time:  6 secs).

+-----------------------------------------------------------------------------+
                                Summaries:
+-----------------------------------------------------------------------------+

Installation Summary
--------------------
Name                        Level           Part        Event       Result
-------------------------------------------------------------------------------
X11.compat.lib.X11R6_motif  6.1.4.1         USR         APPLY       SUCCESS    
X11.compat.lib.X11R6_motif  6.1.4.1         USR         COMMIT      SUCCESS    

install_all_updates: Generating list of updatable rpm packages.
========================================================
The following rpm packages will be updated:
cdrecord 1.9-7
========================================================

install_all_updates: Updating rpm packages..


Validating RPM package selections ...

lsfs: No record matching '/dev/lv05' was found in /etc/filesystems.
fs_size_check[34]: /usr/sbin/ls:  not found
cdrecord                    ##################################################

+-----------------------------------------------------------------------------+
                           RPM  Error Summary:
+-----------------------------------------------------------------------------+
The following errors during installation occurred:
failed to stat /export/mksysb: No such file or directory


install_all_updates: Checking for recommended maintenance level 6100-04.
install_all_updates: Executing /usr/bin/oslevel -rf, Result = 6100-04
install_all_updates: Verification completed.
install_all_updates: Log file is /var/adm/ras/install_all_updates.log
install_all_updates: Result = SUCCESS
Known Recommended Maintenance Levels
------------------------------------
Restoring device ODM database.

+-----------------------------------------------------------------------------+
Executing nimadm phase 7.
+-----------------------------------------------------------------------------+
nimadm: There is no user customization script specified for this phase.

+-----------------------------------------------------------------------------+
Executing nimadm phase 8.
+-----------------------------------------------------------------------------+
Creating client boot image.
bosboot: Boot image is 44903 512 byte blocks.
Writing boot image to client's alternate boot disk hdisk1.

+-----------------------------------------------------------------------------+
Executing nimadm phase 9.
+-----------------------------------------------------------------------------+
Adjusting client file system sizes ...
Adjusting size for /
Adjusting size for /admin
Adjusting size for /audit
Adjusting size for /home
Adjusting size for /opt
Adjusting size for /root
Adjusting size for /tmp
Adjusting size for /trace
Adjusting size for /usr
Expanding /alt_inst/usr client filesystem.
Filesystem size changed to 4653056
Adjusting size for /home/scripts
Adjusting size for /usr/sysload
Adjusting size for /var
Adjusting size for /var/core
Syncing cache data to client ...

+-----------------------------------------------------------------------------+
Executing nimadm phase 10.
+-----------------------------------------------------------------------------+
Unmounting client mounts on the NIM master.
forced unmount of /labotest_alt/alt_inst/var/core
forced unmount of /labotest_alt/alt_inst/var
forced unmount of /labotest_alt/alt_inst/usr/sysload
forced unmount of /labotest_alt/alt_inst/home/scripts
forced unmount of /labotest_alt/alt_inst/usr
forced unmount of /labotest_alt/alt_inst/trace
forced unmount of /labotest_alt/alt_inst/tmp
forced unmount of /labotest_alt/alt_inst/root
forced unmount of /labotest_alt/alt_inst/opt
forced unmount of /labotest_alt/alt_inst/home
forced unmount of /labotest_alt/alt_inst/audit
forced unmount of /labotest_alt/alt_inst/admin
forced unmount of /labotest_alt/alt_inst
Removing nimadm cache file systems.
Removing cache file system /labotest_alt/alt_inst
Removing cache file system /labotest_alt/alt_inst/admin
Removing cache file system /labotest_alt/alt_inst/audit
Removing cache file system /labotest_alt/alt_inst/home

+-----------------------------------------------------------------------------+
Executing nimadm phase 11.
+-----------------------------------------------------------------------------+
Cloning altinst_rootvg on client, Phase 3.
Client alt_disk_install command: alt_disk_copy -j -B -M 6.1 -P3 -d "hdisk1"
## Phase 3 ###################
Verifying altinst_rootvg...
Modifying ODM on cloned disk.
forced unmount of /alt_inst/var/core
forced unmount of /alt_inst/var
forced unmount of /alt_inst/usr/sysload
forced unmount of /alt_inst/home/scripts
forced unmount of /alt_inst/usr
forced unmount of /alt_inst/trace
forced unmount of /alt_inst/tmp
forced unmount of /alt_inst/root
forced unmount of /alt_inst/opt
forced unmount of /alt_inst/home
forced unmount of /alt_inst/audit
forced unmount of /alt_inst/admin
forced unmount of /alt_inst
Changing logical volume names in volume group descriptor area.
Fixing LV control blocks...
Fixing file system superblocks...

+-----------------------------------------------------------------------------+
Executing nimadm phase 12.
+-----------------------------------------------------------------------------+
Cleaning up alt_disk_migration on the NIM master.
Cleaning up alt_disk_migration on client labotest.
</code>

**Now you can reboot**

===== IMPORTANT =====

Disable remote command when finish, and remove .rhosts file

To remove the old_rootvg, you have 2 ways:
<cli>
  * exportvg old_rootvg
  * alt_rootvg_op -X
</cli>

To mount the old filesystems with :  
<cli>
  * alt_rootvg_op -W -d hdisk0
</cli>

To put it into sleep again: 
<cli>
  * alt_rootvg_op -S # add (-t) to recreate boot device 
</cli>
===== Better Migration method (remove SDDPCM) =====

Define a premigration script to remove SDDPCM only on the clone
<cli prompt='>'>
[root@nim1] /root > cat /export/nim/custom_scr_mig72/pre_scr_mig72.sh
#!/usr/bin/ksh

logname=/root/pre_scr_mig72.log
savedir=/root/save_mig72


#------------------------------------------------
main()
{
mkdir -p $savedir

echo "####### Save ssh keys"
cd /etc/ssh ; tar cvf $savedir/ssh_keys.tar .

echo "####### Save ssl config"
cd /var ; tar cvf $savedir/var_ssl.tar /var/ssl
echo "####### Save banner"
cp /etc/motd $savedir

echo "####### Save sendmail.cf"
cp /etc/mail/sendmail.cf $savedir

echo "####### Remove obsolet packages"
for lpp in $(lslpp -Lc | grep devices.ethernet.lnc2.rte |cut -d':' -f2)
do
  installp -u -g $lpp
done

echo "####### Remove obsolet packages"
for lpp in $(lslpp -Lc | egrep "^devices.sddpcm" |cut -d':' -f2)
do
  installp -u -g $lpp
done

}

main 2>&1 | tee $logname
</cli>

<cli prompt='>'>
[root@nim1] /root > lsnim -l pre_scr_mig72
pre_scr_mig72:
   class       = resources
   type        = script
   Rstate      = ready for use
   prev_state  = unavailable for use
   location    = /export/nim/custom_scr_mig72/pre_scr_mig72.sh
   alloc_count = 1
   server      = master
</cli>

Put MPIO and SDDPCM driver in the lppsource, and do the migration for example from AIX 7.1 to 7.2, It will remove sddpcm from clone, and add automaticaly the latest version at the end of the migration
<cli prompt='>'>
[root@nim1] /root > nimadm -c aixsrv1 -l aix7200-01-02_lpp -s aix7200-01-02_spot -d hdisk3 -a pre_scr_mig72 -j nimvg  -Y
</cli>

If you have a kind of message **Verifying alt_disk_migration eligibility /usr/sbin/nimadm[1146]: unknown: bad number**\\
if you believe this disk is bootable, re-execute this command with the **"-g"** (ignore boot check) flag. 
====== How to upgrade AIX using alt_disk and patches ======

**INFO** Modified emgr to block all customization scripts when INUCLIENTS is set. This can be overridden if the FORCE_SCRIPTS environment variable is set (export FORCE_SCRIPTS=yes).

0. Clean and make an extra disk.
<cli prompt='#'>
# alt_disk_install -X      
# alt_disk_install -BCV -e /etc/exclude.rootvg  (hdiskx)
</cli>

1. wake up alt_rootvg
<cli prompt='#'>
# alt_rootvg_op -W -d (hdiskx)
</cli>

2. Confirm installed ifixes
<cli prompt='#'>
# INUCLIENTS=1 chroot /alt_inst /usr/sbin/emgr -l
# e.g.
INUCLIENTS=1 chroot /alt_inst /usr/sbin/emgr -r -L IV07730s03
INUCLIENTS=1 chroot /alt_inst /usr/sbin/emgr -r -L IV09922s03
INUCLIENTS=1 chroot /alt_inst /usr/sbin/emgr -r -L IV12612s03
INUCLIENTS=1 chroot /alt_inst /usr/sbin/emgr -r -L IV12629m03
INUCLIENTS=1 chroot /alt_inst /usr/sbin/emgr -r -L IV13803m03
INUCLIENTS=1 chroot /alt_inst /usr/sbin/emgr -r -L IV13873s03
INUCLIENTS=1 chroot /alt_inst /usr/sbin/emgr -r -L IV13891s03
INUCLIENTS=1 chroot /alt_inst /usr/sbin/emgr -r -L IV16603m03
INUCLIENTS=1 chroot /alt_inst /usr/sbin/emgr -r -L IV17536s03
INUCLIENTS=1 chroot /alt_inst /usr/sbin/emgr -r -L IV19158
INUCLIENTS=1 chroot /alt_inst /usr/sbin/emgr -r -L IV20864s03
</cli>

3. Commit Current applied Fileset
<cli prompt='#'>
# INUCLIENTS=1 chroot /alt_inst /usr/sbin/installp -s
# INUCLIENTS=1 chroot /alt_inst /usr/sbin/installp -cpgX all
# INUCLIENTS=1 chroot /alt_inst /usr/sbin/installp -cgX all
# INUCLIENTS=1 chroot /alt_inst /usr/sbin/installp -s
# INUCLIENTS=1 chroot /alt_inst /usr/bin/lppchk -v
</cli>

4. Install AIX SP
<cli prompt='#'>
# alt_rootvg_op -C -b update_all -I pa -l (patch directory) -V
# alt_rootvg_op -C -b update_all -I agXY -l (patch directory) -V
# INUCLIENTS=1 chroot /alt_inst /usr/bin/oslevel -s
# INUCLIENTS=1 chroot /alt_inst /usr/bin/lppchk -v
</cli>

4.1 Remove Unnecessary fileset.
<cli prompt='#'>
#INUCLIENTS=1 chroot /alt_inst /usr/bin/oslevel -rl 6100-08
#INUCLIENTS=1 chroot /alt_inst /usr/sbin/installp -u devices.msg.en_US.chrp.IBM.HPS.rte
#INUCLIENTS=1 chroot /alt_inst /usr/sbin/installp -u devices.msg.en_US.chrp.IBM.HPS.hpsfu
#INUCLIENTS=1 chroot /alt_inst /usr/bin/oslevel -rl 6100-08
# INUCLIENTS=1 chroot /alt_inst /usr/bin/oslevel -s
</cli>

5. Install PowerHA SP
<cli prompt='#'>
# alt_rootvg_op -C -b update_all -I pa -l (patch directory) -V
# alt_rootvg_op -C -b update_all -I agXY -l (patch directory) -V
# INUCLIENTS=1 chroot /alt_inst /usr/bin/lslpp -l cluster.*
# INUCLIENTS=1 chroot /alt_inst /usr/bin/lppchk -v
</cli>

6. Add vmo parameter "numperm_global" into /etc/tunables/nextboot file
<cli prompt='#'>
# INUCLIENTS=1 chroot /alt_inst /usr/sbin/vmo -FL numperm_global
# INUCLIENTS=1 chroot /alt_inst /usr/sbin/vmo -p -o numperm_global=0
# INUCLIENTS=1 chroot /alt_inst /usr/bin/cat /etc/tunables/nextboot
</cli>

7. Remove xmdaily from inittab.
<cli prompt='#'>
# INUCLIENTS=1 chroot /alt_inst /usr/sbin/lsitab xmdaily
# INUCLIENTS=1 chroot /alt_inst /usr/sbin/rmitab xmdaily
# INUCLIENTS=1 chroot /alt_inst /usr/sbin/lsitab xmdaily
</cli>

8. Check applied Patch and Updated SW
<cli prompt='#'>
# INUCLIENTS=1 chroot /alt_inst /usr/bin/oslevel -s
# INUCLIENTS=1 chroot /alt_inst /usr/bin/lppchk -v
# INUCLIENTS=1 chroot /alt_inst /usr/sbin/emgr -l
# INUCLIENTS=1 chroot /alt_inst /usr/bin/lslpp -l | grep -i cluster
# INUCLIENTS=1 chroot /alt_inst /usr/bin/lslpp -l rsct.core.hostrm
# INUCLIENTS=1 chroot /alt_inst /usr/bin/lslpp -l rsct.core.fsrm
# INUCLIENTS=1 chroot /alt_inst /usr/bin/lslpp -l rsct.core.errm
# INUCLIENTS=1 chroot /alt_inst /usr/bin/lslpp -l rsct.basic.rte
# INUCLIENTS=1 chroot /alt_inst /usr/bin/lslpp -l rsct.core.utils
# INUCLIENTS=1 chroot /alt_inst /usr/bin/lslpp -l rsct.core.rmc
</cli>

9. Sleep altinst_rootvg; Create a bootimage
<cli prompt='#'>
# alt_rootvg_op -S -t
# lspv | grep root ; only the rootvg is active.
# ps -ef | grep -i alt _ ; no /alt file system mounted.
</cli>

10. Check & Change a bootlist
<cli prompt='#'>
# bootlist -m normal -o
# bootlist -m normal hdiskY hdiskZ
# shutdown -Fr
</cli>
 
     
====== AIX: multibos upgrade ======

Multibos, is a clone of the rootvg on the same disk, just the LV name are changed.

By default the BOS filesystems in rootvg (/, /usr, /var, /opt) and the BLV (hd5) are copied. All other filesystems and lvs are shared between BOS instances.

multibos -?                           <--gives info of the parameters

Multibos update:
<cli prompt>
lsvg rootvg | grep FREE               <--checking if we have enough free space in rootvg
multibos -R                           <--remove any standby BOS from earlier (-R: remove)
multibos -sXp                         <--preview the operation (-s:setup, -X:expand fs if needed, -p:preview)
alog -of/etc/multibos/logs/op.alog    <--shows the log file

multibos -sX                          <--creates standby BOS
lsvg -l rootvg | grep bos             <--bos prefix added to the new lvs and fs'

multibos -S                           <--start standby BOS shell (-S:shell operation)
oslevel -s                            <--checking standby BOS level
exit                                  <--leaving standby BOS shell

multibos -Xacp -l /mnt/TL9SP4         <--preview of the update of the standby BOS (-a:update all, -c:customization operation?)
multibos -Xac -l /mnt/TL9SP4          <--updates the standby BOS (when done check new OS level in "multibos -S" (after then exit))

bootlist -m normal -ov                <--check that bootlist is set to standby BOS (-v:verbose)
                                      Check the correct BLV. Compare the output from bootlist with “Welcome to AIX” banner at startup (HMC).
                                      (usually no action is needed, multibos automatically sets the new blv)
                                      
</cli>
e.g:
<cli prompt='#'>
root@aix31: / # bootlist -m normal -ov
'ibm,max-boot-devices' = 0x5
NVRAM variable: (boot-device=/pci@80000002000000c/pci@2/pci1069,b166@1/scsi@0/sd@4:4 /pci@80000002000000c/pci@2/pci1069,b166@1/scsi@0/sd@4:2)
Path name: (/pci@80000002000000c/pci@2/pci1069,b166@1/scsi@0/sd@4:4)    <--check this pathname at startup, to determine which blv is used
match_specific_info: ut=disk/scsi/scsd
hdisk0 blv=bos_hd5
Path name: (/pci@80000002000000c/pci@2/pci1069,b166@1/scsi@0/sd@4:2)    <--as you see the ony difference is the :4 vs :2)
match_specific_info: ut=disk/scsi/scsd
hdisk0 blv=hd5


root@aix31: / # bootlist -m normal -o
hdisk0 blv=bos_hd5
hdisk0 blv=hd5
</cli>

------------------------------------
<cli prompt='#'>
shutdown -Fr                   <--reboot
bootinfo -v                    <--verify which BLV the system booted from (bos_hd5 should be seen)
                               (the new fs' are now mounted and the old ones are renamed to bos_...)
</cli>
if we need to go back to the original OS:
  bootlist -m normal hdisk0 blv=hd5 hdisk0 blv=bos_hd5    <--set the bootlist to the original BLV first
  shutdown -Fr


if you want to keep the upgraded OS (just without the bos_ prefixes):
(0. if you want you can remove the original OS: multibos -R)    <--this will remove the original lvs, which were not upgraded
  1. multibos -sX                <--as we have already bos_ prefixes, it will create the lvs as the original ones: hd2, hd9var, hd5...)
  2. shutdown -Fr                <--BLV will be set to hd5, so the otiginal lvs OS (upgraded) will be boot
  3. multibos -R                 <--removes the bos_ entries from rootvg

The filesystems that multibos copy are /, /usr, /var, and /opt. So if you want to use multibos, you should check that in rootvg you have enough space to duplicate that filesystems.

If you want to use multibos, and then install some efix, you should copy the efix, in some filesystem that multibos duplicate. 


Changing bootlist if desired:
  # bootlist -m normal hdisk0 blv=hd5 hdisk0 blv=bos_hd5

==== clone and upgrade (alt_disk_copy) ====


Reboot the system now with the “shutdown –Fr” command. After the reboot, confirm the TL level via “oslevel –r”. Verify which BLV the system booted from with the “bootinfo –v” command. 

To clone the running 5300-00 rootvg to hdisk3, then apply updates from /updates to bring the cloned rootvg to a 5300-01 level:
<cli prompt>
     alt_disk_copy -d hdisk3 -F 5300-01_AIX_ML -l /updates Copy
</cli>
     
The bootlist would then be set to boot from hdisk3 at the next reboot.
To clone the running rootvg to hdisk3 and hdisk4, and execute update_all on all updates from /updates:
<cli prompt>
     alt_disk_copy -d "hdisk3 hdisk4" -b update_all -l /updates
</cli>   

PREREQUISITES
First things first, we need to make sure the current environment is ready to be copied. The two main things that I look for are:

1. Make sure the current environment doesn’t have any missing filesets.
<cli prompt='>'>
root@AIX / > oslevel -s
6100-05-01-1016
root@AIX / > instfix -i | grep ML
...
    All filesets for 6100-05_AIX_ML were found.
</cli>

**Note: If a particular ML doesn’t return positive (e.g. 6100-05_AIX_ML), use instfix -ciqk 6100-05_AIX_ML | grep “:-:” to see the fileset causing issues and rectify it.

2. Make sure all filesets have been committed. Now I’m not entirely sure if this is a requirement, but I prefer to work with an as clean environment as possible.
<cli prompt='>'>
root@AIX / > lslpp -l | grep -i applied
</cli>

**Note: If you have software which is in an applied state, commit it.

Now that we’re happy with the state of the environment, you need to verify that there is enough room in rootvg to make copies of the following logical volumes [/ (hd4), /usr (hd2), /var (hd9var), /opt (hd10opt) and the boot logical volume (hd5)].

Once we’ve satisfied the above requirement, we can get started with the multibos work. I’m not going to dissect each command, so I suggest reading the multibos man pages to know what each switch does. The only one that I’ll explain is -p, which does a preview of the multibos command executed.

MULTIBOS
1. Remove any previous standby multibos environments. The below command will return a FAILURE status if you don’t have a standby multibos environment. If you’re using multibos for the first time, this will be the case.
<cli prompt='>'>
root@AIX / > multibos -RX
Initializing multibos methods ...
Initializing log /etc/multibos/logs/op.alog ...
Gathering system information ...
multibos: 0565-077 Unable to locate standby BOS.
 
Log file is /etc/multibos/logs/op.alog
Return Status: FAILURE
</cli>

2. Create the standby BOS. New logical volumes and filesystems will be created prefixed and with bos_. This can take a while to complete.

This will preview the creation of the multibos environment and list all the logical volumes that will be copied.
<cli prompt='>'>
root@AIX / > multibos -sXp
...
...
Log file is /etc/multibos/logs/op.alog
Return Status = SUCCESS
</cli>
You can also view the log file using the alog command.

root@AIX / > alog -of /etc/multibos/logs/op.alog

If everything completed successfully, run the command again without the preview.
<cli prompt='>'>
root@AIX / > multibos -sX
</cli>
Once complete, you’ll notice that the new logical volumes will be prefixed with bos_

3. Once complete, you can drop into a multibos shell and check oslevel, it should be the same as the host OS.

The below command will mount all the filesystems required and drop you in a MULTIBOS> prompt
<cli prompt='>'>
root@AIX / > multibos -S
...
...
MULTIBOS> oslevel -s
6100-05-01-1016
</cli>

To umount all the filesystems and break out of the multibos environment.
<cli prompt='>'>
MULTIBOS> exit
</cli>

4. Apply the TL/ML to the multibos environment.

The below command will tell multibos to apply the updates from the specified location (which is the location that your new ML resides).
<cli prompt='>'>
root@AIX / > multibos -Xac -l /home/kristijan/6100-06-04
</cli>
Drop into the multibos shell again and check that the ML has been successfully applied.
<cli prompt='>'>
root@AIX / > multibos -S
MULTIBOS> oslevel -s
6100-06-04-1112
MULTIBOS> instfix -i | grep ML
    	All filesets for 6100-00_AIX_ML were found.
    	All filesets for 6.1.0.0_AIX_ML were found.
    	All filesets for 6100-01_AIX_ML were found.
    	All filesets for 6100-02_AIX_ML were found.
    	All filesets for 6100-03_AIX_ML were found.
    	All filesets for 6100-04_AIX_ML were found.
    	All filesets for 6100-05_AIX_ML were found.
    	All filesets for 6100-06_AIX_ML were found.
MULTIBOS> exit
</cli>

5. Verify that the bootlist now contains blv=bos_hd5. bos_hd5 is the location of the new boot logical volume. It will be at the top of the list when you run the bootlist command.
<cli prompt='>'>
root@AIX / > bootlist -m normal -o
hdisk0 blv=bos_hd5 pathid=0
hdisk0 blv=hd5 pathid=0
</cli>

Managing ifixes in a NIM SPOT resource

To install an ifix into a NIM SPOT resource, place the ifix in an lpp_source in the emgr/ppc subdirectory. For example:
<cli prompt='#'>
# lsnim -a location lpp1
lpp1:
   location = /export/lpp_source/lpp1
# ls -l /export/lpp_source/lpp1/emgr/ppc
-rw-r--r--   root   system  IZ12345.epkg.Z
</cli>

Then, install the ifix using the cust operation:
<cli prompt='#'>
# nim -o cust -a filesets=E:IZ12345.epkg.Z -a lpp_source=lpp1 spot1
</cli>
or, using smitty:
<code>
# smitty nim_inst_latest
* Installation Target                                 spot1
* LPP_SOURCE                                          lpp1
* Software to Install                                [E:IZ12345.epkg.Z]      +
</code>

The E: tells the geninstall program that the software is packaged as an ifix and can be found in the emgr/ppc directory of the lpp_source. You may also create an installp_bundle resource, if you need to install multiple ifixes at once. Each ifix should be listed on a separate line of the bundle file.

To deinstall the ifix:
<cli prompt='#'>
# nim -o maint -a filesets=E:IZ12345 -a installp_flags=u spot1
</cli>
Managing ifixes in an altinst_rootvg

To create a copy of the rootvg and install an ifix to the altinst_rootvg:
<cli prompt='#'>
# alt_disk_copy -d hdisk# -l /ifix_dir -w E:IZ12345.epkg.Z
</cli>
To install an ifix into an altinst_rootvg that has already been created, you first perform a wake-up operation on the altinst_rootvg:
<cli prompt='#'>
# alt_rootvg_op -Wd hdisk#
</cli>
Then, you can install the ifix:
<cli prompt='#'>
# alt_rootvg_op -Cw IZ12345.epkg.Z -l /ifix_dir
</cli>

It is extremely important to put the altinst_rootvg back to sleep after the ifix has been installed:
<cli prompt='#'>
# alt_rootvg_op -S
</cli>

Managing ifixes in a multibos standby instance

The multibos command requires a bundle file that contains a list of the ifixes to be installed in geninstall bundle format. For example:
<cli prompt='#'>
# cat ifixes.bnd
E:IZ12345.epkg.Z
</cli>
To create a new multibos standby instance and install an ifix at the same time:
<cli prompt='#'>
# multibos -Xsl /ifix_dir -b ifixes.bnd
</cli>
To install an ifix into a multibos standby instance that has already been created:
<cli prompt='#'>
# multibos -Xcl /ifix_dir -b ifixes.bnd
</cli>
To deinstall the ifix, use the multibos shell function to open a shell in the standby instance of the OS:
<cli prompt='#'>
# multibos -XS
</cli>
Then, deinstall the ifix and exit the shell:
<cli prompt='>'>
MULTIBOS> emgr -r -L IZ12345
MULTIBOS> exit
#
</cli>

===== Using NIM Alternate Disk Migration (NIMADM) =====

https://www-01.ibm.com/support/docview.wss?uid=isg3T1012571

<code>
Question

How to use NIMADM
Answer

Using NIM Alternate Disk Migration (NIMADM)

What this document will cover:
What is NIMADM
Preparing for a NIMADM
Create a copy of rootvg to a free disk (or disks) and simultaneously migrate it to a new version or release level of AIX
Using a copy of rootvg, create a new NIM mksysb resource that has been migrated to a new version or release level of AIX
Using a NIM mksysb resource, create a new NIM mksysb resource that has been migrated to a new version or release level of AIX
Using a NIM mksysb resource, restore to a free disk (or disks) and simultaneously migrate to a new version or release level of AIX
Waking up and putting to sleep the migrated disk
Using a post migration script with nimadm
Logs used during the nimadm process and sample entries
Debug techniques if nimadm fails
</code>



NIMADM stands for Network Install Manager Alternate Disk Migration
<code>
The nimadm command is a utility that allows the system administrator to do the following:

· Create a copy of rootvg to a free disk (or disks) and simultaneously migrate it to a new version or release level of AIX.

· Using a copy of rootvg, create a new NIM mksysb resource that has been migrated to a new version or release level of AIX.

· Using a NIM mksysb resource, create a new NIM mksysb resource that has been migrated to a new version or release level of AIX.

· Using a NIM mksysb resource, restore to a free disk (or disks) and simultaneously migrate to a new version or release level of AIX.

The nimadm command uses NIM resources to perform these functions.


Preparing for a NIMADM

There are a few requirements that must be met before attempting to use I'll mention just some of these here.

· The NIM master must have the fileset installed in its own rootvg and in the SPOT that will be used for the migration. Both need to be at the same level. It is not necessary to install the alternate disk utilities on the client.

· The lpp_source and SPOT NIM resources that have been selected for the migration MUST match the AIX level to which you are migrating.

· The NIM master (as always) should be at the same or higher AIX level than the level you are migrating to on the client.

· The target client must be registered with the NIM master as a standalone NIM client.
· You will need to have the connection working between the master and client by either using rsh or nimsh.

· The NIM master must be able to execute remote commands on the client using rsh. rsh will need to be working in order for nimadm to work.
· Verify with the following on the client:
· # lssrc -ls inetd
· exec, login, and shell need to be active
· if not all active, please vi /etc/inetd.conf and make sure they are not commented out. If they have a # sign in front, remove the # , save the file and run refresh -s inetd, then verify with lssrc -ls inetd.

· Ensure the NIM client has a spare disk (not allocated to a volume group) large enough to contain a complete copy of its rootvg. If rootvg is mirrored, break the mirror and use one of the disks for the migration.

· Ensure the clients NIM master has a volume group (for example, nimadmvg) with enough free space to cater for a complete copy of the client's rootvg. If more than one AIX migration is occurring for multiple NIM clients, make sure there is capacity for a copy of each clients rootvg.
</code>

<code>
Create a copy of rootvg to a free disk (or disks) and simultaneously migrate it to a new version or release level of AIX

Creating a migrated copy of rootvg on another disk is probably the most common and straight forward use of nimadm. It dramatically reduces the amount of downtime compared to just doing a normal nim migration. As long as you have a free disk or disks large enough for a migrated copy of the rootvg and a nim server that is at the same level or higher than the level you want to migrate to this can be done. Once it completes you just reboot to the migrated disk and you are back up at the migrated level. If you discover any problems at the new level you just need to change the boot list back to the previous disk and reboot.

To perform a nimadm via SMIT do the following on the nim master:
# smitty nimadm
Perform NIM Alternate Disk Migration

Perform NIM Alternate Disk Migration

Type or select values in entry fields.
Press Enter AFTER making all desired changes.

[TOP] [Entry Fields]
* Target NIM Client [select your client]
* NIM LPP_SOURCE resource [select the lpp_source]
* NIM SPOT resource [select the spot]
* Target Disk(s) to install [select the disk(s) you want to migrate to]
DISK CACHE volume group name []

NIM IMAGE_DATA resource []
NIM BOSINST_DATA resource []
NIM EXCLUDE_FILES resource []
NIM INSTALLP_BUNDLE resource []
NIM PRE-MIGRATION SCRIPT resource []
NIM POST-MIGRATION SCRIPT resource []

Phase to execute [all]
NFS mounting options []
Set Client bootlist to alternate disk? yes
Reboot NIM Client when complete? no
Verbose output? no
Debug output? no

ACCEPT new license agreements? No <-- change this to yes

Nothing else is required but it is recommended to enter a volume group for disk caching in order to avoid NFS issues.
</code>


If you prefer to use command line, the command would be:
<cli prompt='#'>
# nimadm -c client_hostname -l lpp_source -s spot -d target_disk(s)
</cli>

In order to also include a volume group for disk caching you would use the following command:
<cli prompt='#'>
# nimadm -c client_hostname -l lpp_source -s spot -j VG_name -d target_disk(s) -Y
</cli>




Using a copy of rootvg, create a new NIM mksysb resource that has been migrated to a new version or release level of AIX

If you have a nim client and you need a mksysb of it that can be put on another system that requires a higher release or version than the client is currently at, this will accomplish that.

There isn’t currently a way to do a Client to mksysb Migration via SMIT, you will need to use command line on the nim master:

To accomplish a Client to mksysb Migration via command line you would do the following:
<cli prompt='#'>
# nimadm –c client -O path_migrated_mksysb_file -s spot -l lpp_sourc> -j VGname -Y -N new_nim_mksysb_name
</cli>





To accomplish a mksysb to mksysb Migration via command line you would do the following:
<cli prompt='#'>
# nimadm -T current_mksysb_resource -O path_migrated_mksysb_file -s spot -l lpp_source name -j VGname -Y -N new_nim_mksysb_name
</cli>

Waking up and putting to sleep the migrated disk

There may be times that you want to wake up the migrated disk.
This should be done from the nim server, not the client, using the following command:
<cli prompt='#'>
# nimadm –W -c client -s spot -d target_disk
</cli>

After waking it up, be sure to put it back to sleep before rebooting.
That can be done with the following command:
<cli prompt='#'>
# nimadm –S -c client -s spot
</cli>



Using a post-migration script with nimadm

There may be times when you want to remove and/or install some other filesets after the migration completes. You can do that with a post-migration NIM script.

The nimadm utility can perform both pre and post migration tasks. This is accomplished by running NIM scripts either before or after a migration. The tool accepts the following flags for pre and post migration script resources:

-a PreMigrationScript Specifies the pre-migration NIM script resource.
-z PostMigrationScript Specifies the post-migration NIM script resource.

pre-migration

This script resource that is run on the NIM master, but in the environment of the client's alt_inst file system that is mounted on the master (this is done by using the chroot command). This script is run before the migration begins.


post-migration

This script resource is similar to the pre-migration script, but it is executed after the migration is complete.

I will give an example of a post-migration only, although the configuration is the same for both.

In this example I will show you how to uninstall and install a fileset.



===== Debug techniques if nimadm fails =====

If nimadm fails, it’s best to first look at the logs to determine the cause of failure. If there isn’t enough information in the logs to determine the problem it may be necessary to run nimadm in debug mode.

Debug mode can be enabled by using the **–D** option if you are using command line or by setting Debug output? to yes if you are using smitty nimadm

There are many times that problems with nimadm can be resolved by using disk caching. That will eliminate issues that arise due to slow networks and/or NFS issues. Disk caching can be enabled by using the **–j** option and specifying the volume group to use on the nim master to perform the nimadm. If you are using smitty nimadm you would specify the volume group to use with DISK CACHE volume group name.

Since this is a migration you will want to verify that your system is in a consistent state before performing the nimadm.
On the client, run the following commands:
<cli prompt='#'>
# oslevel –s this will tell you what level the system is currently at
# oslevel –sq the highest level that is output should match the oslevel –s output from above.
# lppchk –v this should return to the prompt with no output
# lsvg rootvg | grep SIZE verify the size is at least 32 megabytes
# bosboot –ad /dev/ipldevice verify the boot image is created and there are no errors.
</cli>

For additional checks you may want to do prior to the nimadm you may want to review the Preparing to Migrate document at

http://www-01.ibm.com/support/docview.wss?uid=isg3T1011431

If you have a pre-migration script resource defined on your nim master you can specify for that to be run. If you do it will be run during phase 4 of the nimadm process.

If you get an error similar to the following:
<cli prompt='#'>
0505-205 nimadm: The level of bos.alt_disk_install.rte installed in SPOT <spot> (0.0.0.0) does not match the NIM master's level
</cli>

You will need to verify the level of bos.alt_disk_install.rte on the master and in the spot.
To check the master:
<cli prompt='#'>
# lslpp –l bos.alt_disk_install.rte
</cli>

To check the spot:
<cli prompt='#'>
# nim –o showres <spot> | grep bos.alt_disk_install.rte
</cli>
If the levels aren’t the same (or if the spot doesn’t have the fileset) you can install/update it with <cli prompt='#'>
smitty nim_inst_all
</cli>

Then select the spot and the lpp_source that has the same level fileset that is on the master, then for <cli prompt='#'>
Software to Install enter bos.alt_disk_install.rte
</cli>

Although there are many different kinds of errors possible with nimadm, having the correct level of bos.alt_disk_install.rte in the spot and doing the pre-migration checks and using the cache option will eliminate most of them. For anything else a debug output will probably be needed for further analysis.
wiki

User Tools

Site Tools

Page Tools
