PACKAGE: Update Release 3.1.4.21
IOSLEVEL: 3.1.4.21
VIOS level is |
The AIX level of the NIM Master
level must be equal to or higher than |
Update Release 3.1.4.21 |
AIX
7200-05-06 |
Be sure to heed all minimum space requirements before
installing.
Review the list of fixes included in Update Release 3.1.4.21
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.4.21.
Microcode or system firmware
downloads for Power Systems
If the VIOS being updated has filesets installed from
the VIOS Expansion Pack, be sure to update those filesets with the latest VIOS
Expansion Pack if updates are available.
Update Release 3.1.4.21
updates your VIOS partition to ioslevel 3.1.4.21.
To determine if Update Release 3.1.4.21
is already installed, run the following command from the VIOS command line.
$ ioslevel
If Update Release 3.1.4.21
is installed, the command output is 3.1.4.21.
For Customers using NVMe Over
Fabric (SAN) as their Boot Disk
Booting from NVMeoF disk may fail if
certain fabric errors are returned, hence a boot disk set up with multiple
paths is recommended. In case there is a failure to boot, the boot
process may continue if you exit from the SMS menu. Another potential
workaround is to discover boot LUNs from the SMS menu and then retry boot.
For Customers Using Third Party
Java-based Software
This only applies to customers who both use third
party Java based software and have run updateios -remove_outdated_filesets to
remove Java 7 from their system.
To prevent errant behavior when editing customer’s /etc/environment file,
updateios does not make changes to that file when run. If a customer is using
software that depends on using Java and having the path to it in your PATH
environment variable, the following edit should be made to allow programs that
use the PATH environment variable to locate Java 8.
In
the /etc/environment file, customers should see:
PATH=[various
directories]:/usr/java7_64/jre/bin:/usr/java7_64/bin
To
address a potential issue with Java-dependent third party software, this should
be converted to:
PATH=[various
directories]:/usr/java8_64/jre/bin:/usr/java8_64/bin
Note
If the Virtual I/O servers are
installed on POWER10
systems and configured with “32Gb PCIe4 2-Port FC Adapter,
Feature Code(s) EN1J and EN1K”, then the requirement is to update the adapter
microcode level to 7710812214105106.070115 before updating the Virtual
I/O server to 3.1.4.21 level.
Please refer to the release notes at this link
VIOS 3.1.4.21 adds the
following new features:
VIOS Shared
Storage Pool Logging Enhancements
The two major enhancements for VIOS Shared Storage
Pool in this release are as follows:
· The
creation of dbn.log file
within a
Shared Storage Pool (SSP).
This file tracks all elections and
relinquishes of the Database Node (DBN) role and debugs DBN-related problems
easily.
· The
compression and storage of vio_daemon logs.
The number of logs
that can be retained is increased by 15 times with no impact to storage
capacity. This is done by compressing old VIOS logs and by tagging them
with appropriate date and time information. This reduces the risk of logs that
might contain critical information from being overwritten by newer logs.
N_Port ID Virtualization (NPIV) Enhancements: NVMeoF
Protocol Support
The NPIV is a
standardized method for virtualizing a physical Fibre Channel (FC) port. An
NPIV-capable FC host bus adapter (HBA) can have multiple N_Ports, each
with a unique identity. The NPIV, coupled with the adapter-sharing capabilities
of the Virtual I/O Server (VIOS), allows a physical Fibre Channel HBA to be
shared across multiple guest operating systems. The PowerVM implementation of
NPIV enables POWER® logical partitions (LPARs)
to have virtual fibre channel host bus adapters,
each with a dedicated
worldwide port name.
Each virtual Fibre Channel HBA has a unique storage area network (SAN) identity
similar to that of a dedicated physical HBA.
The Non-Volatile Memory Express over Fabrics (NVMeoF) protocol in the NPIV stack
is supported in Virtual I/O Server Version 3.1.4.0. A single virtual adapter
provides access to both Small Computer Systems Interface (SCSI) and NVMeoF
protocols if the physical adapter can support them. The application, which is
running on the client partition and capable of handling the NPIV-NVMeoF
protocol, can send I/Os in parallel to SCSI and NVMeoF disks that are coming
from a single virtual adapter. The hardware and software requirements for
NVMeoF protocol enablement in the NPIV stack are as follows:
· VIOS
Version 3.1.4.0, or later
· NPIV-NVMeoF
capable client (currently AIX®
Version 7.3
Technology Level 01, or later)
· POWER
10 system with firmware version FW 1030, or later
· 32
or 64 GB FC adapters with physical NVMeoF support
VIOS
Operating System Monitoring Enhancement
This release adds support for monitoring the VIOS
operating system state by the POWER Hypervisor. If the VIOS
partition is not responsive (due to certain conditions), then the hypervisor
restarts the VIOS partition while it takes the system dump for debugging
purpose. This helps to recover the VIOS partition from errors, for example, if
the CPU is hijacked by the highest-level interrupt, the system progress is
stopped. The ioscli viososmon command
is added to understand the hang detection interval and the action when
the hang is detected. This support requires POWER firmware
version FW
1030, or later and VIOS Version 3.1.4.0, or later.
Support for NFSv4 Mounts on VIOS
The ioscli mount command which previously,
by default, only supported the NFSv3 mount of the AIX is updated to
support NFSv4 mounting. The changes allow VIOS to be able to invoke commands
for the following actions:
·
Setting Network File System (NFS) domain using chnfsdom from
command line interface (CLI)
The setting of the
NFS domain is accomplished by adding a Role-based access control (RBAC) support
for the chnfsdom command.
· Invoking
the NFSv4 mounting
The ioscli mount command
is updated to support invoking the NFSv4 mounting. The current ioscli
mount command defaults to NFSv3. You can invoke the “o vers=4” option with the new “-nfsvers <version> <Node: > <Directory> <
Directory>” option that is added
to the ioscli mount command. The values
that are supported for the version are 3 and 4.
Note: The ioscli
mount command
supports NFS versions that are supported by the AIX
mount
command.
· Starting
the nfsrgyd daemon
For version 4, if
the mount is successful, a check is done to see if the nfsrgyd daemon is
already started. And if it has not yet started, the nfsrgyd daemon is
started.
VIOS 3.1.4.21 can run on any of the following Power
Systems:
POWER 8 or later.
The following requirements and limitations apply to Shared Storage Pool
(SSP) features and any associated virtual storage enhancements.
Software Installation
SSP Configuration
Feature |
Min |
Max |
Number of
VIOS Nodes in Cluster |
1 |
16* |
Number of
Physical Disks in Pool |
1 |
1024 |
Number of
Virtual Disks (LUs) Mappings in Pool |
1 |
8192 |
Number of
Client LPARs per VIOS node |
1 |
250* |
Capacity
of Physical Disks in Pool |
10GB |
16TB |
Storage
Capacity of Storage Pool |
10GB |
512TB |
Capacity
of a Virtual Disk (LU) in Pool |
1GB |
4TB |
Number of
Repository Disks |
1 |
1 |
Capacity
of Repository Disk |
512MB |
1016GB |
Number of
Client LPARs per Cluster |
1 |
2000 |
Prerequisites for expanded support:
Here are the new maximum values for each of these
configuration options, if the associated hardware specification has been met:
Feature |
Default
Max |
High
Spec Max |
Number of
VIOS Nodes in Cluster |
16 |
24 |
Number of Client
LPARs per VIOS node |
250 |
400 |
Network Configuration
Storage Configuration
Shared Storage Pool capabilities and limitations
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.4.21. Run the lsvg
rootvg command, and then ensure
there is enough free space.
Example:
$ lsvg rootvg |
|
|
|
VOLUME GROUP: |
rootvg |
VG IDENTIFIER: |
00f6004600004c000000014306a3db3d |
VG 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: |
2 |
STALE PVs: |
0 |
STALE PPs: |
0 |
ACTIVE PVs: |
1 |
AUTO ON: |
yes |
MAX PPs per VG: |
32512 |
|
|
MAX PPs per PV: |
1016 |
MAX PVs: |
32 |
LTG size (Dynamic): |
256 kilobyte(s) |
AUTO SYNC: |
no |
HOT SPARE: |
no |
BB POLICY: |
relocatable |
PV RESTRICTION: |
none |
INFINITE RETRY: |
no |
A single, merged
lpp_source is not supported for VIOS that uses SDDPCM. However, if you use
SDDPCM, you can still enable a single boot update by using the alternate method
described at the following location:
SDD and SDDPCM migration
procedures when migrating VIOS from version 1.x to version 2.x
Virtual I/O Server support for Power Systems
VIOS Update
Release 3.1.4.21 may be applied directly to any VIOS at level 3.1.0.00.
The VIOS must
first be upgraded to 3.1.0.00 before the 3.1.4.21 update can be applied. To learn more about how to do that, please
read the information provided 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.4.21 using rolling
updates.
Non-disruptive
rolling updated 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.4.21 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.
Instructions: Verify
the cluster is running at the same level as your node.
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 Fileset
bos.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:
$ rules -o deploy -d
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.
2. Using ftp, transfer the update file(s) to the directory you created.
To apply updates from a remotely mounted file system, and the remote file
system is to be mounted read-only, follow the steps:
The update release
can be burned onto a CD by using the ISO image file(s). To apply updates from
the CD/DVD drive, follow the steps:
$ shutdown
-restart
Note: If shutdown –restart command failed, run swrole –PAdmin 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
APAR |
Description |
IJ38295 |
MIG_VNIC: GET_VF_DRC_NAME() DO NOT REPORT ACCURATE RETURN CODE |
IJ41237 |
NPIV MULTIPLE QUEUES ONLY ENABLED ON FIRST LPM AFTER BOOT OR REC |
IJ41531 |
SECLDAPCLNTD MEMORY LEAK IN _GETALLGRP_LDAP |
IJ41650 |
SERVER CRASHES WITH PKCS11 KERNEL EXTENSION |
IJ42211 |
Logical Volume device driver (LVDD) performance improvements |
IJ43763 |
ARTEX XML FILE FOR HDISKPOWER SHOULD CALL CHDEV -P |
IJ43781 |
OSLEVEL_S IS NOT UPDATED FOR MKSYSB TO MKSYSB MIGRATION |
IJ43876 |
A potential security issue exists |
IJ44425 |
fix CVE_2022_2795 Security vulnerabilities |
IJ44485 |
snap needs to capture the /var/adm/ras/errtmplt file |
IJ44501 |
THE SECURITY.ACF PRE-DELETE SCRIPT STOPS THE SSH DAEMON |
IJ44509 |
IOSCLI MKSVM CAUSES CRASH WITH 00CB LED ON VIOS 3.1 |
IJ44559 |
A potential security issue exists |
IJ44560 |
A potential security issue exists |
IJ44650 |
NIM INSTALLATION WITH ADAPTER ID 8680FF1514100000 WILL BE SLOW. |
IJ44665 |
VNIC BACKING DEVICE GOES INTO DEAD STATE AFTER FIRMWARE UPDATE |
IJ44784 |
/etc/qconfig lost or truncated to 0 bytes |
IJ44785 |
strptime not working for %y year, %C date and time |
IJ44789 |
Add gzip option for kernel compression |
IJ44794 |
system might hang if error occurs on check condition recovery |
IJ44795 |
vNIC failover failure due to extended complete network outage |
IJ44797 |
Missing storage key restore in scsidisk_close error path |
IJ44801 |
[c11] complex macros fail to build with unresolved |
IJ44808 |
Strings command should exit if passed directory as parameter |
IJ44809 |
cpio fails to list or restore from |
IJ44810 |
2022E-JORDAN AND SYRIA SWITCH TO YEAR-ROUND +03 |
IJ44811 |
IANA Olson TZ DST Updates for 2022a-2022g |
IJ44883 |
bitais01 |
IJ44955 |
qdaemon fills console log with redundant error messages |
IJ44965 |
CORE DUMP IN SECLDAPCLNTD |
IJ44980 |
vfc adapter reset after migration upon ACA condition from |
IJ44981 |
Path loss after adapter reset |
IJ44994 |
A potential security issue exists |
IJ44994 |
A potential security issue exists |
IJ45019 |
nmon not closing the FIFO files opened for SEA adapters |
IJ45036 |
nextafter does not return 'NaN' when passed |
IJ45037 |
MEMORY LEAK WHEN CAA CLUSTER CONFIGURED WITH VLAN |
IJ45043 |
DURING HBA FW UPDATE,IO ARE NOT PROCESSED ON NPIV UPDATED PATH |
IJ45062 |
CAA: UNABLE TO CUSTOMIZE THE CAA.DEBUG LINE IN SYSLOG.CONF |
IJ45073 |
LOCK CONTENTION ISSUES DURING ERROR RECOVERY |
IJ45105 |
errlog from pfcdd on failure to invalidate the data. |
IJ45113 |
RMUSER CHECKS FOR USER'S RUNNING PROCESSES WITHOUT -C FLAG |
IJ45237 |
strftime() returned incorrect formatted string |
IJ45238 |
strftime_l returuned incorrect formatted string |
IJ45241 |
Adapter driver fatal event could cause hang during unmap of vfc |
IJ45242 |
Disk driver delays too long after write error |
IJ45245 |
A potential security issue exists |
IJ45263 |
VSCSI RW_TIMEOUT HANDLING IMPROVEMENTS |
IJ45375 |
Disk path failures during runtime config on VIOS |
IJ45423 |
Some cmds may fail for non root users post LKU |
IJ45453 |
Data corruption with Netapp Asymmetric Namespace Access(ANA) |
IJ45465 |
After microcode update, the microcode level is not reflected for
all ports. |
IJ45474 |
Wrong return check for odm_get_list() |
IJ45512 |
DSI IN NFS.EXT:NFS4LOOKUP_ACCESS_MISS |
IJ45516 |
liveupdate preview can fail if a pmsvcs system call fails |
IJ45519 |
crash in tcp_output+001F74 |
IJ45575 |
Update kernel copyright notice for 2023 |
IJ45619 |
SECLDAPCLNTD NEEDS TO CALL LDAP_STOP_TLS_S_NP |
IJ45621 |
Observing VIOS crashed after large number of vfc mapping/ |
IJ45624 |
breakpoint information error for p10 |
IJ45765 |
Observing VIOS crash in VFC host |
IJ45818 |
/USR/DT/BIN/DTMAIL FAILS WITH SYMBOL __DL__FPV (NUMBER 221) |
IJ45909 |
A potential security issue exists |
IJ46344 |
Update Diagnostics VRMF for Spring 2023 |
IJ46450 |
Advanced Diagnostics Internal serial wrap test failure on EN2N |
IJ46454 |
lpar crashed @rtfree@AF70_34+0002DC |
IJ46532 |
First time disk open takes longer time |