Configuring resources for Live Update

Edit online

Configure the following resources for the AIX® Live Update operation to complete successfully: CPU, memory, storage, I/O, and lvupdate.data file.

CPU and memory

The extra amount of CPU and memory resources that are required temporarily during the Live Update operation is equal to the amount of current resources that are used by the logical partition that must be updated with any interim fix installed. These CPU and memory resources must be available on the same frame when the Live Update operation is initiated, and are released by the time the Live Update operation completes. The following approaches reduce the impact of this requirement:

  • Enable Capacity on Demand (CoD) resources during the AIX Live Update operation on hosts that are managed by the Hardware Management Console (HMC).

    If sufficient unlicensed and deactivated resources are available in the server that contains the logical partition that must be updated, the Live Update function automatically activates Enterprise Pool CoD resources until the Live Update operation is complete. Enterprise Pool CoD resources can be acquired in the following cases:

    • The compliance state of the pool must not be out of compliance according to your CoD licensing agreement.
    • If more resources are activated, the total number of activated Enterprise Pool CoD resources must not exceed twice the number of entitled Enterprise Pool CoD resources.
    For other types of CoD resources, you must manually enable the CoD resources before you start the Live Update operation.
    Note: If you see "1430-187 WARNING: Couldn't release the unreturned mobile CoD resources generated on CEC 'hostname'.", check configuration of the Enterprise Pool, and make required updates to the resource allocation.
  • Use Dynamic Logical Partitioning (DLPAR) to reduce the CPU and memory resources by half before the Live Update operation, and then increase them again when the Live Update operation is complete. This method impacts the performance of the partition during the Live Update operation, but it allows the operation to complete with no extra resources.
  • Configure Live Update to allow the Live Update operation to run on another host. This process is only available if the host is managed by the IBM® Power® Virtualization Center (PowerVC). Use the lvupdate.data file to indicate that the Live Update operation can be run on another host if the CPU or memory resources are insufficient on the initial host. To implement this process, the partition is automatically migrated by using the PowerVC Live Update operation. This migration process is temporary. You can use the force_migration option in the lvupdate.data file to force Live Update to run on another host, even if sufficient CPU and memory resources are available on the local host.
Storage

The Live Update operation requires at least 2 extra disks. The first disk (or set of disks) is required for the initial boot disk of the surrogate partition. This disk is shown as lvup_rootvg when you use the lspv command, and is not available for reuse until after the next Live Update operation, or after a system reboot. As part of the Live Update operation, an entry is added to the /etc/inittab file to remove the lvup_rootvg label on the disk (or set of disks) so the disk is available for general use after reboot. If the system is not rebooted, a subsequent Live Update operation on a different disk removes the lvup_rootvg label from the previously used disk, which is then available for general use. The second disk (or set of disks) is required to create an extra mirror of the root volume group.

If the Live Update operation includes only interim fixes, this new mirror is not updated and is renamed to old_rootvg at the completion of the Live Update operation. In this case, this mirror copy can be used after the Live Update operation to move the system back to the previous level, if required, by rebooting the partition from this old_rootvg mirror. If any updates were applied with the Live Update operation, the new mirror includes the updates and is not named old_rootvg. In this case, it is a best practice to create a backup of the rootvg before you start the Live Update operation if you want to move the system back to the previous level.

For PowerVC managed partitions, the Live Update operation does not create an old_rootvg mirror. In this case, you can back up the rootvg before you start the Live Update operation if you want to move the system back to the previous level.

This disk can also be reused for another purpose. Depending on the system configuration, more temporary disks might be required. If paging space is present on a non-rootvg disk, or if a memory dump device is present on the non-rootvg disks, two sets of disks must be provided. One set of disk for the original partition and another set of disk for the surrogate partition. The two sets of disks that are provided must have enough capacity for these paging spaces and memory dump devices. The preview mode of the Live Update operation can compute the required amount of space. These disks are available for reuse when the Live Update operation completes.

If you want to update and HMC managed LPAR, the required storage devices must be specified in the disk stanza of the lvupdate.data file. For PowerVC managed LPAR, the PowerVC manages the storage devices, and the disk names are not specified.

If the Live Update operation fails, it logs information in the /var/adm/ras/liveupdate/logs directory. This information might be required for service support. New log files are created in this directory with subsequent Live Update operations and the older log files are renamed to include the timestamp in its names. These older log files can be removed, if required, to free some space.

Reliability, availability, and serviceability (RAS) information that is associated to the Live Update operation is available in the /var/adm/ras/liveupdate directory. Component traces are available in the ct_dump directory, and the lightweight memory traces are available in the lmt_dump directory. If the Live Update trace is enabled, the trcfile_orig file contains traces for the original node and the trcfile_surr file contains traces for the surrogate node. Live dumps during the Live Update operation are collected in the /var/adm/ras/livedump directory.

If any service issue occurs with the Live Update operation, the snap -U command collects all the required information for the support team.

I/O

All I/O must be virtualized through Virtual I/O Servers (VIOS) for the Live Update operation. All VIOS slot numbers are the same on both the VIOS servers and the client when the Live Update operation completes. At least two paths must exist to all disks. Half of the paths are removed from the original partition and used from the surrogate partition during the Live Update operation, and all paths are moved to the surrogate partition before the Live Update operation completes. The Live Update operation can work with the following multipathing solutions: IBM AIX Multipath I/O and IBM Subsystem Device Driver Path Control Module (SDDPCM).

There are some device Object Data Manager (ODM) attributes that can be changed but the new values do not take effect until the next system reboot. Since the Live Update operation acts as a system reboot, any such attributes take effect as a result of the Live Update operation.

lvupdate.data file

When you perform a Live Update operation, the geninstall command searches for a stanza file that is called lvupdate.data located in the /var/adm/ras/liveupdate path. The lvupdate.data file contains relevant input data that is required for the Live Update operation. The /var/adm/ras/liveupdate/lvupdate.template file contains the latest descriptions of all possible fields for Live Update operation. The following example is a sample lvupdate.template file that contains description of the basic fields:

# IBM_PROLOG_BEGIN_TAG 
# This is an automatically generated prolog. 
#  
# bos73D src/bos/usr/sbin/liveupdate/lvupdate.template/lvupdate.template 1.26 
#  
# Licensed Materials - Property of IBM 
#  
# COPYRIGHT International Business Machines Corp. 2014, 2023 
# All Rights Reserved 
#  
# US Government Users Restricted Rights - Use, duplication or 
# disclosure restricted by GSA ADP Schedule Contract with IBM Corp. 
#  
# IBM_PROLOG_END_TAG 
# %Z%%M%        %I%  %W% %G% %U%
#
# The lvupdate.template file can be used to create the 
# /var/adm/ras/liveupdate/lvupdate.data file, which is
# required for Live Update (geninstall -k ... ).
# If the LPAR that you want to update is managed by HMC, the pvc stanza 
# does not apply and it must not be specified.
# If the LPAR that you want to update is managed by PowerVC, the disks and hmc
# stanzas do not apply and these stanzas must not be specified.
# All fields in the disks stanza can be one disk or a comma-separated 
# list of disks.
#
# If preview is entered as part of the geninstall command_line or
# in the SMIT menus, then no lvupdate.data file is required. If one is
# provided, and the disks stanza completed, then size checking on the
# disks will be performed.
#
# general:
#      kext_check =  <yes | no>  Blank defaults to yes. If no, the live update 
#         operation will be attempted regardless as to whether all the loaded
#         kernel extensions are determined to be safe or not.
#      cpu_reduction = <yes | no> Blank or omitted defaults to no. If yes, the
#         live update operation will, in the absence of sufficient processing
#         capacity to create and boot the surrogate normally, determine whether
#         removing some capacity from the original would result in sufficient
#         available capacity, and if so, will automatically remove
#         the capacity from the original (later to restore the surrogate to full
#         capacity once the original is deleted).
#
# disks:
#      nhdisk = <disk1,disk2,...>  The names of disks to be used to make a copy
#         of the original rootvg which will be used to boot the Surrogate
#         (surr-boot-rootvg). The required size needs to match the total size
#         of the original rootvg logical volumes except for an unmounted jfs2
#         logical volume which is not included in the required size calculation. 
#         (If previewing, size checking will be performed.)
#      mhdisk = <disk1,disk2,...>  The names of disks to be used to temporarily
#         mirror rootvg on the Original LPAR. The mirror will be split, with 
#         the original rootvg moved to the Surrogate LPAR and the newly created 
#         mirror staying on the Original LPAR. After the live update, the mhdisk 
#         disk(s) will be available for re-use. If previewing, size checking will 
#         be performed.
#      alt_nhdisk = <disk1,disk2,...>  The names of disks to be used if the disks 
#         specified for the nhdisk attribute are not currently available
#         to be used by Live Update. The capacity requirements are
#         the same as nhdisk. Useful for doing multiple Live Updates.
#      tohdisk = <disk1,disk2,...>  The names of disks to be used as temporary
#         storage for the Original. This is only required if the Original
#         is using paging space or dump devices on non-rootvg volume groups. The
#         capacity needs to match the total capacity of paging spaces and dump
#         devices defined on non-rootvg volume groups for the original
#         partition. (If previewing, size checking will be performed.)
#      tshdisk = <disk1,disk2,...>  The names of disks to be used as temporary
#         storage for the Surrogate. This is only required if the Original is
#         using paging space or dump devices on non-rootvg volume groups. It
#         must have the same capacity as tohdisk. (If previewing, size checking
#         will be performed.)
#
# hmc:
#      lpar_id = <lpar id>  Indicates the desired partition id for the
#         Surrogate.
#      alt_lpar_id = <lpar id>  Indicates an alternate partition ID for the
#         Surrogate. If the value specified for the 'lpar_id' attribute is already in use,
#         Live Update will use this alternate ID if it is not in use. Useful
#         for doing multiple Live Updates.
#      management_console = <HMC IP Address>
#      user = <HMC user>  This is the user id to be used for access to the HMC.
#
# pvc:
#      management_console = <hostname or IP Address of the server hosting 
#         the PowerVC identity service>
#      user = <PowerVC user>  This is the user ID to be used to access PowerVC.
#      project = <PowerVC project>  This is the project to be used to access
#         PowerVC. If the attribute is not specified, "ibm-default" is used.
#      storage_template_override = <storage template name>  Indicates the name
#         of the storage template used for the boot volume of the surrogate.
#         This parameter is optional.
#         The storage template is defined as follow:
#          1. use this parameter if specified, or
#          2. use the storage template of the original rootvg if any, or
#          3. use the default storage template of the rootvg storage provider.
#      destination = < PowerVC host name | ANY >  This attribute is used to
#         specify the host on which the Live Update operation will be executed
#         if the resources are insufficient on the local host, or if the
#         force_migration attribute is specified with a value equals to yes.
#         If the attribute is set to ANY, the destination will be selected
#         according to the placement policy of the host group in PowerVC.
#         If this parameter or its value is not specified, the Live Update
#         operation is executed locally.
#      force_migration = < yes | no >  When set to yes, the Live Update
#         operation is executed on the host specified by the destination
#         attribute even if the resources are sufficient locally.
#         This parameter is optional and can be set to yes only when a
#         destination is specified.
#      pvc_disable_storage_model_check = < yes | no >  When set to yes, the
#         Live Update operation will disable the storage provider validatioin
#         for pluggable and integrated type. This parameter is optional and can
#         be set to yes only when user want to disable storage provider check. 
#      pvc_disable_moveadapter = < yes | no >  When set to yes, the
#         Live Update operation will not use the move adapter feature to do LKU
#         in PowerVC managed system. It will use disk attach mechanism.
#
# trace:
#      trc_option = <trace command options>  This can be a hook id
#         with -j hookid1,... or any other trace option.
#         If specified, the live update commands will be traced using
#         the specified options. One or more can be specified.
#         If the stanza is present in the lvupdate.data file, 
#         with a blank trc_option field, the default parameters 
#         "-a -U -C and -o" are used to trace the live update commands.
#         Users need not provide redundant options such as "-a -U -C and -o"
#         in the trc_option field for trace stanza.
#         Do not add a trace stanza to the lvupdate.data file unless you
#         want the live update commands to be traced. 
#

general:
	kext_check = 

disks:
	nhdisk  = 
	mhdisk  = 
	tohdisk = 
	tshdisk = 

hmc:
	lpar_id  = 
	management_console = 
	user =