====== VIOS Upgrade ======


Before starting, refer to the IBM Web site (Central fixes), and look at the readme to check which step you have to follow to upgrade.
  * Don't use NIM resources for upgrade, it's not supported, and it can crash your VIOS. It can only be used for migration (Ex 1.5 to 2), or for restore from mksysb.

Example: upgrade of vios4

==== Check Backups ====

  * Check if the mksysb of the VIOS are consistent (on the VIOS /home/scripts/log/) and available on NIM servers.
  * Check if the last VIOS cfgbackups (map) is also present on NIM server (/export/mksysb/cfgbackups)

==== Change path priority on VIOS clients ====

To be able to redirect that LAN and Vscsi traffic from on a specific VIOS, we have to know which LPAR is on a server

Extract from HMC the list of LPAR (without VIOS):
<cli prompt='#'>
[root@nimsrv]/root# /home/scripts/bin/chpathpriority2.sh -h hmc1           
         P520-srv1 P520-srv2 P520-srv3 
[root@nimsrv]/root# /home/scripts/bin/chpathpriority2.sh -h hmc1 -m P520-srv1
         lpar01 lpar02 lpar03 lpar04
</cli>
			
Verify vscsi adapters map to VIOS on each client, from NIM server:	
<cli prompt='#'>
[root@nimsrv]/root# for i in lpar01 lpar02 lpar03 lpar04
do
ssh $i /home/scripts/bin/show_path_missmatch.sh 
done
</cli>
If no result, everything is normal, else stop this procedure and correct the errors.

Change disk PATH priority on client partitions, in this script specify the VIOS on which the traffic must be, during upgrade:	
<cli prompt='#'>
[root@nimsrv]/root# for i in lpar01 lpar02 lpar03 lpar04
do
/home/scripts/bin/chpathpriority2.sh -h hmc1 -m P520-srv1 -p $i  -v vios3 -f
done
</cli>
	
Now change SEA availbility, put all SEA from VIOS to upgrade in standby mode:
<cli prompt='#'>
[padmin@vios4]/home/padmin# lsdev -type adapter | grep Shared
ent6             Available   Shared Ethernet Adapter
ent9             Available   Shared Ethernet Adapter
ent14            Available   Shared Ethernet Adapter
[padmin@vios4]/home/padmin# chdev  -dev ent6 -attr ha_mode=standby
[padmin@vios4]/home/padmin# chdev  -dev ent9 -attr ha_mode=standby
[padmin@vios4]/home/padmin# chdev  -dev ent14 -attr ha_mode=standby
</cli>

You can check the change into errlog, on both VIOS, vios4 and vios3, adapters become PRIMARY or STANDBY:
<cli prompt='#'>
[padmin@vios4]/home/padmin# errlog
</cli>


==== VIOS Upgrade ====

Don't use NIM resources, it's not supported, and it can crash your VIOS. Connect to VIOS as padmin (connect also as pseudo root if additionnal steps are required after upgrade, and before reboot)
<cli prompt='#'>
[padmin@vios4]/home/padmin# ioslevel
2.1.2.13-FP-22.1 SP-02	
</cli>

Mount the update using NFS:			
<cli prompt='#'>
[padmin@vios4]/home/padmin# mkdir mnt
[padmin@vios4]/home/padmin# mount nimsrv:/export/vios22 /home/padmin/mnt
</cli>

Optional you can use check sum to certify your CD:
<cli prompt='#'>
[padmin@vios4]/home/padmin# ./mnt/ck_sum.bff /mnt
 “All VIOS update files, verified correctly.”
</cli>

If you have EFIX installed, first remove it as root:
<cli prompt='>'>
[padmin@vios4]/home/padmin> for i in $(emgr -P | grep IV | sort -r | awk '{print $3}')
do
emgr -r -L $i
done

</cli> 
Commit previous updates, and apply the new level:
<cli prompt='#'>
[padmin@vios4]/home/padmin# updateios -commit
[padmin@vios4]/home/padmin# updateios -dev mnt/vios2.2 -accept	
</cli>

Do not perform any action before the end of upgrade, else it will failed.

Now reboot the VIOS, if no additional action is required (refer to readme on IBM Web site)
<cli prompt='#'>
[padmin@vios4]/home/padmin# shutdown -restart
</cli>

**Additional tasks:**
  * Most time there are always eFIX to apply on VIOS, wich required or not a reboot. Install it as padmin, with updateios  command, as previous.
  * Follow also the AIX post upgrade [[aix:post_upgrade|AIX Upgrade, postinstall actions]]
  * Check after reboot, as padmin		
<cli prompt='#'>
      # ioslevel	
</cli>
  * As pseudo-root
<cli prompt='#'>
      # oslevel
      # instfix -ci | grep :-:
</cli>
  * Upgrade sdd and mpio drivers if needed, as padmin if possible, else as pseudo-root, and reboot if needed
  * Apply also efix if needed:
<cli prompt='#'>
      # updateios -accept -install -dev <directory_name >
</cli>


==== Remove or update problem filesets ====

DO NOT USE SMITTY use 
  updateios –remove bos.suma


==== Change path priority on VIOS clients ====

To be able to balance LAN and Vscsi traffic to both VIOS.

From NIM server:

Balance Vscsi traffic:
<cli prompt='#'>
[root@nimsrv]/root# for i in lpar01 lpar02 lpar03 lpar04
do
ssh  $i /home/scripts/bin/change_disk_param.sh -f
done
</cli>

Verify with:
<cli prompt='#'>
[root@nimsrv]/root# for i in lpar01 lpar02 lpar03 lpar04
do
ssh  $i /home/scripts/bin/show_path_missmatch.sh
done
</cli>
If no output, then everything is OK.

On the VIOS, vios4:

Reactivate the SEA in normal state:
<cli prompt='#'>
[padmin@vios4]/home/padmin# chdev  -dev ent6 -attr ha_mode=auto
[padmin@vios4]/home/padmin# chdev  -dev ent9 -attr ha_mode=auto
[padmin@vios4]/home/padmin# chdev  -dev ent14 -attr ha_mode=auto
</cli>

You can check the change into errlog, on both VIOS, vios4 and vios3, adapters become PRIMARY or STANDBY:
<cli prompt='#'>
[padmin@vios4]/home/padmin# errlog
</cli>

Now verify the path state on all LPAR, from NIM, check unavalaible paths:	
<cli prompt='#'>
[root@nimsrv]/root# /usr/bin/dsh 'lspath | grep -v Enable'
</cli>

**IMPORTANT** Apply the same procedure on the second VIOS. Always maintain both VIOS at same level.



====== VIOS upgrade to version 3.1 ======

Starting with PowerVM version 2.2.6.32, you have a new command: **viosupgrade**

The upgrade VIOS use an alternate disk method, so original disk won't be alter. 

Steps automatically done during migration, you can't stop it once starting:
- mksysb is copied on the new disk (alt_rootvg)
- config is saved on alternate disk (viosbr)
- reboot
- reconfiguration of the VIOS (mapping, SEA....), sometimes the network hag during less than 10 seconds!
- reboot

If you need to install exfix use the same command 
<cli prompt='$'>
$ updateios -install -dev /home/padmin/backups/ifix -accept
</cli>

===== Prerequisites =====

Add a new free disk on the VIOS 

Save config files:
  tar cvf /tmp/ssh_keys.tar /etc/ssh/*key*
  ioscli lsmap -all > /tmp/lsmap-all.txt
  ioscli lsmap -all -npiv > /tmp/lsmap-all-npiv.txt
  pcmpathq > /tmp/pcmpathq.txt
  lsdev -Cc adapter > /tmp/lsdev-Ccadapter.txt
  for i in $(lsdev -Cc adapter | awk '{print $1}') ; do echo "######## $i" ; lsattr -El $i ;done  > /tmp/lsattr.txt
  netstat -in > /tmp/netstat-in.txt


===== Extract image (mksysb) from ISO =====

Original image can be downloaded from IBM web site

Mksysb can be extract by mounting the ISO file with type **UDFS** !!! not **ISO**
  # loopmount -i VIOS_31010_Flash.iso -m /mnt -o "-V udfs -o ro"

===== Migrate the VIOS using alternate disk =====

Non-SSP: 
<cli prompt='$'>
[padmin@vios01]/home/padmin$ viosupgrade -l -i /tmp/vios31.mksysb -a hdisk33 -g /tmp/filelist
</cli>

With SSP (storage pool): 
<cli prompt='$'>
[padmin@vios01]/home/padmin$ viosupgrade -l -i /tmp/vios31.mksysb -a hdisk33 -g /tmp/filelist -c
</cli>
  -g file of filenames that will get copied for you to the new disk = really neat! (Ex: /etc/ssh/*key* not supported)
  -c = cluster = Shared Storage Pool

<code>
# cat /tmp/filelist
/etc/ssh/ssh_host_dsa_key
/etc/ssh/ssh_host_ecdsa_key
/etc/ssh/ssh_host_ed25519_key
/etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_dsa_key.pub
/etc/ssh/ssh_host_ecdsa_key.pub
/etc/ssh/ssh_host_ed25519_key.pub
/etc/ssh/ssh_host_rsa_key.pub
</code>
Also list the state of the upgrade with: viosupgrade -l -q

Post migration\\
If you have started on a base VIOS image, the login into the console to change the padmin password

Backup files are located in **/home/padmin/backup_files/**

Logs: **/home/ios/logs/**

https://www.ibm.com/developerworks/community/blogs/cgaix/resource/viosupgrade_altdisk_v3_GA.pdf?lang=en