PACKAGE: Update Release 3.1.2.10
IOSLEVEL: 3.1.2.10
|
VIOS level is |
NIM Master level must be equal to or higher than |
|
Update Release 3.1.2.10 |
AIX 7200-05-01 |
Please refer to the VIOS Maintenance Strategy here for more details regarding the change to the VIOS release numbering scheme.
Be sure to heed all minimum space requirements before installing.
Review the list of fixes included in Update Release 3.1.2.10
To take full advantage of all the functions available in the VIOS, it may be necessary to be at the latest system firmware level. If a system firmware update is necessary, it is recommended that the firmware be updated before you update the VIOS to Update Release 3.1.2.10.
Microcode or system firmware downloads for Power Systems
Update Release 3.1.2.10 updates your VIOS partition to ioslevel 3.1.2.10. To determine if Update Release 3.1.2.10 is already installed, run the following command from the VIOS command line.
$ ioslevel
If Update Release 3.1.2.10 is installed, the command output is 3.1.2.10.
A database manager change has occurred for Shared Storage Pool (SSP). This change will have no direct impacts on behavior, however it does mean that non-disruptive upgrades of an SSP cluster to 3.1.X.X requires that SSP nodes first are updated to version 2.2.6.31 or higher before upgrading to a version of 3.1.0.0 or higher.
Once all VIOS nodes in the cluster have been updated to the latest 2.2.6.X version, double check that rolling upgrade has completed. This can be done by checking the output of “cluster -status -verbose” while logged in as padmin on one of the VIOS nodes in the cluster. Then, check the output for each node, and check for this field:
Node Upgrade Status: 2.2.6.31 ON_LEVEL
If all nodes have 2.2.6.31 or newer, and all say that they are “ON_LEVEL,” then upgrades to the VIOS to 3.1.0.00 or newer can occur without disruption to the SSP cluster.
Additionally, backup and restore can be used to restore older versions of the SSP cluster to 3.1.X.X versions of the VIOS.
Note: 3.1.X.X nodes are unable to join SSP clusters that contain nodes below level 2.2.6.31 or clusters with exclusively 2.2.6.31 or higher nodes prior to the nodes completing a rolling upgrade and saying that they are ON_LEVEL.
Lastly, customers that do not use Shared Storage Pool will be unaffected by this change.
Please ensure that your rootvg contains at least 30 GB and that there is at least 4GB free space before you attempt to update to Update Release 3.1.2.10. Run the lsvg rootvg command, and then ensure there is enough free space.
Example:
$ lsvg rootvg VOLUME GROUP: rootvg VG IDENTIFIER: 00f6004600004c000000014306a3db3dVG STATE: active PP SIZE: 64 megabyte(s)VG PERMISSION: read/write TOTAL PPs: 511 (32704 megabytes)MAX LVs: 256 FREE PPs: 64 (4096 megabytes)
LVs: 14 USED PPs: 447 (28608 megabytes)OPEN LVs: 12 QUORUM: 2 (Enabled)TOTAL PVs: 1 VG DESCRIPTORS: 2STALE PVs: 0 STALE PPs: 0ACTIVE PVs: 1 AUTO ON: yesMAX PPs per VG: 32512 MAX PPs per PV: 1016 MAX PVs: 32LTG size (Dynamic): 256 kilobyte(s) AUTO SYNC: noHOT SPARE: no BB POLICY: relocatable PV RESTRICTION: none INFINITE RETRY: no Virtual I/O Server support for Power Systems
VIOS Update Release 3.1.2.10 may be applied directly to any VIOS that is at either level 3.1.2.00.
This Service Pack release is only
intended for customers that are running at exactly 3.1.2.00. If you are running
at any early version, you should get the Fix Pack release which can be found here.
Warning: The update may fail if there is a loaded media repository.
To check for a loaded media repository, and then unload it,
follow these steps.
1.
To check
for loaded images, run the following command:
$ lsvopt
The Media column lists any loaded media.
2.
To unload media
images, run the following commands on all Virtual Target Devices that have
loaded images.
$ unloadopt -vtd <file-backed_virtual_optical_device >
3.
To verify
that all media are unloaded, run the following command again.
$ lsvopt
The command output should show No
Media for all VTDs.
The Virtual I/O Server (VIOS) Version 2.2.2.1 or later, supports
rolling updates for SSP clusters. The VIOS can be updated to Update Release 3.1.2.10
using rolling updates.
A non-disruptive rolling update to VIOS 3.1 requires all SSP
nodes to be at VIOS 2.2.6.31 or later. See detailed instructions in the VIOS
3.1 documentation
The rolling updates enhancement allows the user to apply Update
Release 3.1.2.10 to the VIOS logical partitions in the cluster individually
without causing an outage in the entire cluster. The updated VIOS logical
partitions cannot use the new SSP capabilities until all VIOS logical
partitions in the cluster are updated.
To upgrade the VIOS logical partitions to use the new SSP
capabilities, ensure that the following conditions are met:
· All VIOS logical
partitions must have VIOS Update Release version 2.2.6.31 or later installed.
· All VIOS logical
partitions must be running. If any VIOS logical partition in the cluster is not
running, the cluster cannot be upgraded to use the new SSP capabilities.
1.
Run the
following command:
$ cluster -status -verbose
2.
Check the Node
Upgrade Status field, and you should see one of the following terms:
UP_LEVEL: This means that the software level of the logical partition is higher
than the software level the cluster is running at.
ON_LEVEL: This means the software level of the logical partition and the
cluster are the same.
There is now a method to verify the VIOS update files before
installation. This process requires access to openssl by the 'padmin' User,
which can be accomplished by creating a link.
Instructions: Verifying VIOS update files.
To verify the VIOS update files, follow these steps:
1.
$ oem_setup_env
2. Create a link to
openssl
# ln -s /usr/bin/openssl
/usr/ios/utils/openssl
3.
Verify
the link to openssl was created
# ls -alL /usr/bin/openssl
/usr/ios/utils/openssl
4.
Verify
that both files display similar owner and size
5. # exit
Use one of the following methods to install the latest VIOS
Service Release. As with all maintenance, you should create a VIOS backup
before making changes.
If you are running a Shared Storage Pool configuration, you must
follow the steps in Migrate Shared Storage Pool Configuration.
Note: While running 'updateios' in the following steps, you may see accessauth messages, but these messages can safely be
ignored.
Version Specific Warning: Version 2.2.2.1, 2.2.2.2, 2.2.2.3, or
2.2.3.1
You must run updateios command twice to get
bos.alt_disk_install.boot_images fileset update problem fixed.
Run the following command after the step of "$ updateios
–accept –install –dev <directory_name >" completes.
$ updateios –accept –dev
<directory_name >
Depending on the VIOS level, one or more of the LPPs below may
be reported as "Missing Requisites", and they may be ignored.
MISSING REQUISITES:
X11.loc.fr_FR.base.lib 4.3.0.0 # Base Level Fileset bos.INed 6.1.6.0 # Base Level Fileset bos.loc.pc.Ja_JP 6.1.0.0 # Base Level Fileset bos.loc.utf.EN_US 6.1.0.0 # Base Level Filesetbos.mls.rte 6.1.x.x # Base Level Fileset
Warning: If VIOS rules have been deployed.
During update, there have been occasional issues with VIOS Rules files getting
overwritten and/or system settings getting reset to their default values.
To ensure that this doesn’t affect you, we recommend making a
backup of the current rules file. This file is located here:
/home/padmin/rules/vios_current_rules.xml
First, to capture your current system settings, run this command:
$ rules -o
capture
Then, either copy the file to a backup location, or save off a
list of your current rules:
$ rules -o list > rules_list.txt
After this is complete, proceed to update as normal. When
your update is complete, check your current rules and ensure that they still
match what is desired. If not, either overwrite the original rules file
with your backup, or proceed to use the ‘rules -o modify’ and/or ‘rules -o add’
commands to change the rules to match what is in your backup file.
Finally, if you’ve failed to back up your rules, and are not sure
what the rules should be, you can deploy the recommended VIOS rules by using
the following command:
Then, if you wish to copy these new VIOS recommended rules to your
current rules file, just run:
$ rules -o capture
Note: This will overwrite any customized rules in the current rules
file.
Applying Updates
Warning:
If the target node to be updated is part of a redundant VIOS
pair, the VIOS partner node must be fully operational before beginning to
update the target node.
Note:
For VIOS nodes that are part of an SSP cluster, the partner node
must be shown in 'cluster -status '
output as having a cluster status of OK and a pool status of OK. If the target
node is updated before its VIOS partner is fully operational, client LPARs may
crash.
Instructions: Applying updates to a VIOS.
To apply updates from a remotely mounted file system, and the remote file
system is to be mounted read-only, follow the steps:
$ shutdown -restart
Note: If shutdown –restart command failed, run swrole –PAdmin in order for padmin to set
authorization and establish access to the shutdown command properly.
$ clstartstop -start -n
<cluster_name > -m
<hostname >
$ ioslevel
Instructions: Checking for an incomplete installation caused by a loaded media
repository.
After installing an Update Release, you can use this method to
determine if you have encountered the problem of a loaded media library.
Check the Media Repository by running this command:
$ lsrep
If the command reports: "Unable to retrieve repository data
due to incomplete repository structure," then you have likely encountered
this problem during the installation. The media images have not been lost and
are still present in the file system of the virtual media library.
Running the lsvopt command should show the media images.
Instructions: Recovering from an incomplete installation caused by a loaded
media repository.
To recover from this type of installation failure, unload any
media repository images, and then reinstall the ios.cli.rte package. Follow these steps:
1.
Unload any
media images
$ unloadopt -vtd <file-backed_virtual_optical_device>
2.
Reinstall
the ios.cli.rte fileset by running the following
commands.
To escape the restricted shell:
$ oem_setup_env
To install the failed fileset:
# installp –Or –agX ios.cli.rte –d <device/directory >
To return to the restricted
shell:
# exit
3.
Restart the
VIOS.
$ shutdown –restart
4.
Verify
that the Media Repository is operational by running this command:
$ lsrep
For additional details, including known capabilities, limitations, and additional install considerations, as well as some additional instructions, please reference the readme for fix pack 3.1.2.10 located here.
This version will include all fixes found in all previous 3.1.2.X releases. The fixes for the previous release can be found here.
|
APAR |
Description |
|
IJ28922 |
crash with large
number of VFC client adapters |
|
IJ28939 |
Extended functions in
pollset.h cause g++ compile error |
|
IJ28926 |
kdb may core dump
during snap collection |
|
IJ28919 |
LKU fails when shared
library file permissions are changed. |
|
IJ29061 |
PowerVM response to
XSD request has invalid data |
|
IJ28993 |
Probable system crash
with NVMe Over Fibre Channel Traffic |
|
IJ29089 |
System dump with IO
failed with " -4" status |
|
IJ28923 |
VFC client driver
loops forever on unexpected PHYP return code. |
|
IJ28924 |
VNIC Client Logical
Link Down CMD returns Link Up status |
|
IJ28995 |
VNIC failover backing
VF can get stuck in LINK DOWN state |