Minimize VIOS Downtime With Alternate Disk Updates
Chris Gibson shows how to use the updateios command to update a VIOS from 4.1.2.00 to 4.2.1.10
Updating a Virtual I/O Server (VIOS) is a routine task for Power administrators, but it is not without risk. Even when an update goes smoothly, it typically involves updating the VIOS rootvg that is currently being used to provide I/O (storage and network) services to its client LPARs, followed by a reboot on the updated existing environment.
VIOS 4.1.2.00 introduced a new capability that provides an alternative approach. The updateios command can now install a VIOS update onto an alternate disk, leaving the currently running VIOS installation untouched. Once the update has completed successfully, the alternate disk can be selected as the boot disk and the VIOS can be rebooted into the new level.
This provides a simple way to separate the update process from the running VIOS environment and, importantly, provides a straightforward fallback if something goes wrong.
In this article, I’ll walk through a real-world example of using this capability to update a VIOS from 4.1.2.00 to 4.2.1.10. I’ll show the commands used, what happens to the disks during the update, how the new VIOS installation is selected for boot, and how the result is verified after the reboot.
Important Fixes!
This new feature requires you to install an interim fix (ifix) on top of VIOS 4.1.2.00. The required ifix is IJ59424m0a.260805.epkg.Z, which is a “combo” fix that contains fixes for IJ59424 (updateios with “-altdisk” fails for nvme disk) and IJ59448 (updateios with “-altdisk” fails with bosboot error). The steps to install the ifix are contained in this article from the IBM support team: Issues Encountered During VIOS Update Using updateios with Alternate Disk. Be sure to obtain this fix and carefully follow the instructions to install it before you attempt to use this new alternate-disk feature. Note, the instructions to install the ifix are unique, so please be sure to follow the steps as outlined in the support article. Without this fix installed correctly, the alternate disk method will be unsuccessful.
Prior to Update
Always take a backup first. Use the backupios and viosbr tools to create a bootable backup of your VIOS and a backup of your virtual device configuration, before you start any maintenance activity.
Verify that the current VIOS level is 4.1.2.00 with the ioslevel command. And ensure that no virtual optical media is loaded using the lsvopt command; note the command output should show “No Media” for all VTDs. The update may fail if there is a loaded media repository.
[padmin@sys854-vios1]$ ioslevel
4.1.2.00
[padmin@sys854-vios1]$ lsvopt
VTD Media Size(mb)
an11dg-cd0 No Media n/a
Review the current disks assigned to the VIOS. You will need a spare, unused disk that is the same (or larger) size as the current rootvg disk. In our example the current rootvg is located in hdisk2, and we will use the unassigned hdisk9 as the alternate rootvg for the updates.
[padmin@sys854-vios1]$ lspv
NAME PVID VG STATUS
hdisk0 00cc5315d1fb8198 viosv3_rootvg
hdisk1 00cc5315d20724ab None
hdisk2 00cc5315d2074c05 rootvg active
hdisk3 00cc5315d20773e5 None
hdisk4 00cc531561898b1d None
hdisk5 00cc53151d7887bc None
hdisk6 00cc53158db2403d None
hdisk7 00cc531590bb673c datavg active
hdisk8 00cc5315c09c3fd2 None
hdisk9 00cc5315ffba7000 None
hdisk10 00cc5315ffba74f9 datavg active
The current rootvg disk is 100GB is size, as confirmed by the lsmpio command below.
[padmin@sys854-vios1]$ lsmpio -ql hdisk2
Device: hdisk2
Vendor Id: IBM
Product Id: 2145
Revision: 0000
Capacity: 100.00GiB
Machine Type: 2145
Model Number: DH8
Host Group: sys854-dev-vios
Volume Name: sys854-dev-vios-hdisk2
System Name: Pok-Edu-Class
Volume Serial: 6005076801808795600000000002B5AD (Page 83 NAA)
The lspv -free command confirms that hdisk9 is indeed free and is 130G in size. Which is more than adequate space to create a clone of the current rootvg.
[padmin@sys854-vios1]$ lspv -free
NAME PVID SIZE(megabytes)
hdisk3 00cc5315d20773e5 102400
hdisk4 00cc531561898b1d 10240
hdisk5 00cc53151d7887bc 133128
hdisk6 00cc53158db2403d 133128
hdisk8 00cc5315c09c3fd2 133128
hdisk9 00cc5315ffba7000 133128
One small word of warning when selecting a free disk. Just because a disk is not assigned to a volume group and/or it doesn’t appear to be mapped to a client LPAR as a VSCSI device, it does not necessarily mean that the disk is not in use. The disk may be assigned for other purposes that are not immediately apparent, such as for Live Partition Mobility (LPM), Simplified Remote Restart (SRR) or for VIOS Shared Storage Pool (SSP) pool disks. Caution is advised when selecting disks. If possible, it is often safer to assign a new disk to the VIOS for use with the altdisk update process.
One way to determine if a disk is already assigned to a volume group, or already in use, is to use the readvgda command. As the root user (from oem_setup_env), on the VIOS, run the readvgda command to view the VG descriptor area on a disk (if one exists). If there is evidence that the disk has a volume group signature (note logical volume names like hd5, hd6, etc, which typically indicate a disk was part of a root volume group at some point), then further investigation is needed. If a disk is currently managed by a different logical volume manager, such as a SSP cluster, the readvgda command will display the message “Disk managed by alternate volume manager, version=32003”. Please refer to the VIOS Updates: Harnessing the Power of Alternate Disk Update blog post for more information on choosing an alternate disk, and cleaning and reusing a disk for this purpose.
You should review and collect lsmap output before the update. This information is also saved to in the viosbr backup file. However, it’s handy to have this information on hand so that you can quickly compare the virtual device configuration before and after the update. In the example below we collect both virtual SCSI and SEA configuration information.
[padmin@sys854-vios1]$ lsmap -all
SVSA Physloc Client Partition ID
--------------- -------------------------------------------- ------------------
vhost0 U8286.41A.06C5315-V1-C3 0x00000002
VTD vtscsi0
Status Available
LUN 0x8100000000000000
Backing device hdisk1
Physloc U78C9.001.WZS0M2D-P1-C7-T2-W500507680C52334E-L1000000000000
Mirrored false
…etc…
[padmin@sys854-vios1]$ lsmap -all -net
SVEA Physloc
------ --------------------------------------------
ent10 U8286.41A.06C5315-V1-C2-T1
SEA ent12
Backing device ent4
Status Available
Physloc U78C9.001.WZS0M2D-P1-C6-T1
…etc…
Updating the VIOS Using an Alternate Disk
Now we will update our VIOS from 4.1.2.00 to 4.1.2.10. By specifying the -altdisk option with the updateios command, we can perform the update on the alternate disk (hdisk9). While this is happening our VIOS continues to run, uninterrupted, on its current rootvg disk (hdisk2). In the example updateios command below, we specify the location of the updates (-dev /home/padmin/VIOS_FP_4.1.2.10). We also specify that we want to perform an installation of the updates (-install). We accept all the license agreements (-accept). And finally, we specify that the current rootvg should be cloned to hdisk9 and the updates applied to the cloned rootvg (-altdisk hdisk9).
updateios -dev /home/padmin/VIOS_FP_4.1.2.10 -install -accept -altdisk hdisk9
As soon as you enter the command you’ll immediately observe that the rootvg is cloned (to hdisk9 in this case).
[padmin@sys854-vios1]$ updateios -dev /home/padmin/VIOS_FP_4.1.2.10 -install -accept -altdisk hdisk9
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.
...etc...
After several minutes, the updates are then applied to the rootvg clone. After the initial installation preview is performed, you are then prompted to answer yes (y) or no (n) to continue with the installation of the updates. Unless you identify an issue with the proposed updates in the preview output, you should enter y to continue. Many filesets will be updated on the clone and it will take about 45 minutes to complete this process. When the update is complete the alternate rootvg is quiesced and updateios exits successfully.
...etc...
Bootlist is set to the boot disk: hdisk9 blv=hd5
+-----------------------------------------------------------------------------+
ATTENTION: calling new module /usr/sbin/alt_rootvg_op. Please see the
alt_rootvg_op man page and documentation for more details.
Executing command: /usr/sbin/alt_rootvg_op -W -d hdisk9
+-----------------------------------------------------------------------------+
Waking up altinst_rootvg volume group ...
*******************************************************************************
installp PREVIEW: installation will not actually occur.
*******************************************************************************
...etc...
******************************************************************************
End of installp PREVIEW. No apply operation has actually occurred.
******************************************************************************
Continue the installation [y|n]?
y
...etc...
Filesets processed: 293 of 352 (Total time: 36 mins 25 secs).
installp: APPLYING software for:
bos.sysmgt.loginlic 7.3.4.1
Filesets processed: 294 of 352 (Total time: 36 mins 30 secs).
installp: APPLYING software for:
bos.net.snapp 7.3.4.1
. . . . . << Copyright notice for bos.net >> . . . . . . .
Licensed Materials - Property of IBM
5765CD300
Copyright International Business Machines Corp. 2000, 2026.
All rights reserved.
US Government Users Restricted Rights - Use, duplication or disclosure
restricted by GSA ADP Schedule Contract with IBM Corp.
. . . . . << End of copyright notice for bos.net >>. . . .
...etc...
rsct.opt.storagerm 3.3.4.2 USR APPLY SUCCESS
rsct.opt.storagerm 3.3.4.2 ROOT APPLY SUCCESS
rsct.opt.stackdump 3.3.4.2 USR APPLY SUCCESS
rsct.opt.stackdump 3.3.4.2 ROOT APPLY SUCCESS
rsct.opt.softwarerm 3.3.4.2 USR APPLY SUCCESS
rsct.opt.softwarerm 3.3.4.2 ROOT APPLY SUCCESS
rsct.compat.basic.rte 3.3.4.2 USR APPLY SUCCESS
rsct.compat.basic.rte 3.3.4.2 ROOT APPLY SUCCESS
bos.suma 7.3.4.2 USR APPLY SUCCESS
bos.suma 7.3.4.2 ROOT APPLY SUCCESS
dsm.core 7.3.4.2 USR APPLY SUCCESS
dsm.core 7.3.4.2 ROOT APPLY SUCCESS
bos.esagent 7.3.4.2 USR APPLY SUCCESS
bos.esagent 7.3.4.2 ROOT APPLY SUCCESS
installp: * * * A T T E N T I O N ! ! !
Software changes processed during this session require
any diskless/dataless clients to which this SPOT is
currently allocated to be rebooted.
+-----------------------------------------------------------------------------+
ATTENTION: calling new module /usr/sbin/alt_rootvg_op. Please see the
alt_rootvg_op man page and documentation for more details.
Executing command: /usr/sbin/alt_rootvg_op -S
+-----------------------------------------------------------------------------+
Putting volume group altinst_rootvg to sleep ...
forced unmount of /alt_inst/var/vio/VMLibrary
forced unmount of /alt_inst/var/vio/VMLibrary
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/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
Fixing LV control blocks...
Fixing file system superblocks...
[padmin@sys854-vios1]$
After the update is complete you will observe that there is a new volume group named altinst_rootvg, and it is assigned to the disk you specified, in this example hdisk9.
[padmin@sys854-vios1]$ lspv
NAME PVID VG STATUS
hdisk0 00cc5315d1fb8198 old_rootvg
hdisk1 00cc5315d20724ab None
hdisk2 00cc5315d2074c05 rootvg active
hdisk3 00cc5315d20773e5 None
hdisk4 00cc531561898b1d None
hdisk5 00cc53151d7887bc None
hdisk6 00cc53158db2403d None
hdisk7 00cc531590bb673c datavg active
hdisk8 00cc5315c09c3fd2 None
hdisk9 00cc5315ffba7000 altinst_rootvg active
hdisk10 00cc5315ffba74f9 datavg active
You’ll also notice that the VIOS bootlist was automatically changed to point to the alternate rootvg disk, hdisk9.
[padmin@sys854-vios1]$ bootlist -mode normal -ls
hdisk9 blv=hd5 pathid=0
Now all that is required is to restart the VIOS from the alternate disk. This can be performed at a time that is convenient to the VIOS administrator.
[padmin@sys854-vios1]$ shutdown -restart
Shutting down the VIO Server could affect Client Partitions. Continue [y|n]?
y
After the VIOS has restarted, the first thing to check is that the VIOS level has updated to 4.1.2.10. The ioslevel command will display the current level.
[padmin@sys854-vios1]$ ioslevel
4.1.2.10
You should also check that the virtual device mapping and SEA adapter configuration are all intact after the update and reboot. Use the lsmap command to display the virtual configuration details, just as you did prior to installing the update.
[padmin@sys854-vios1]$ lsmap -all -net ; lsmap -all | more
SVEA Physloc
------ --------------------------------------------
ent10 U8286.41A.06C5315-V1-C2-T1
SEA ent12
Backing device ent4
Status Available
Physloc U78C9.001.WZS0M2D-P1-C6-T1
SVEA Physloc
------ --------------------------------------------
ent11 U8286.41A.06C5315-V1-C4-T1
SEA NO SHARED ETHERNET ADAPTER FOUND
SVSA Physloc Client Partition ID
--------------- -------------------------------------------- ------------------
vhost0 U8286.41A.06C5315-V1-C3 0x00000002
VTD vtscsi0
Status Available
LUN 0x8100000000000000
Backing device hdisk1
Physloc U78C9.001.WZS0M2D-P1-C7-T2-W500507680C52334E-L1000000000000
Mirrored false
...etc...
Fall Back if Needed
What if there was ever a need to fall back to previous VIOS level? This is very simple to do. All that is required is to change VIOS bootlist to point to the old_rootvg disk and restart the VIOS. In the lspv output below you’ll notice that old_rootvg is assigned hdisk2. This disk contains the previous level of the VIOS, 4.1.2.00. Using the bootlist command we can set the bootlist to hdisk2 and then reboot the VIOS using the command shutdown -restart.
[padmin@sys854-vios1]$ lspv
NAME PVID VG STATUS
hdisk0 00cc5315d1fb8198 viosv3_rootvg
hdisk1 00cc5315d20724ab None
hdisk2 00cc5315d2074c05 old_rootvg
hdisk3 00cc5315d20773e5 None
hdisk4 00cc531561898b1d None
hdisk5 00cc53151d7887bc None
hdisk6 00cc53158db2403d None
hdisk7 00cc531590bb673c datavg active
hdisk8 00cc5315c09c3fd2 None
hdisk9 00cc5315ffba7000 rootvg active
hdisk10 00cc5315ffba74f9 datavg active
[padmin@sys854-vios1]$ bootlist -mode normal hdisk2
[padmin@sys854-vios1]$ bootlist -mode normal -ls
hdisk2 blv=hd5 pathid=0
hdisk2 blv=hd5 pathid=1
hdisk2 blv=hd5 pathid=2
hdisk2 blv=hd5 pathid=3
hdisk2 blv=hd5 pathid=4
[padmin@sys854-vios1]$ shutdown -restart
Shutting down the VIO Server could affect Client Partitions. Continue [y|n]?
y
Once the VIOS finished booting from the old_rootvg disk, you can quickly check that the previous VIOS level is active using the ioslevel command again.
[padmin@sys854-vios1]$ ioslevel
4.1.2.00
As you can see, utilizing this method makes rolling back to the previous VIOS level very easy.
Conclusion
The ability to update a VIOS onto an alternate disk provides another useful option for VIOS maintenance. By keeping the existing VIOS installation intact while the new level is prepared, the update process becomes more flexible and provides a straightforward fallback if the update does not go as planned.
In this article, the VIOS was successfully updated from 4.1.2.00 to 4.2.1.10 using the alternate-disk capability of updateios. Once the alternate disk was selected as the boot disk and the VIOS rebooted, the system came up running the new VIOS level.
For environments where VIOS availability and a simple recovery path are important, this is a capability worth considering when planning future VIOS updates and upgrades.
Want to learn more about VIOS updates, upgrades and management? Attend the IBM PowerVM: Implementing Virtualization and Mastering Virtual I/O Server Upgrades courses. Refer to the links in the references section for more information about each class.
References
VIOS Updates: Harnessing the Power of Alternate Disk Update
Issues Encountered During VIOS Update Using updateios with Alternate Disk
VIOS 4.1.2.10 Fix Pack Release Notes
IBM PowerVM: Implementing Virtualization
Mastering Virtual I/O Server Upgrades