Fix Readme
Abstract
Downloads for Workload Partition Manager for AIX
Content
IBM PowerVM Virtual I/O Server
Contents
This Readme contains installation and other information about VIOS Update Release 2.2.1.9
Package information
PACKAGE: Update Release 2.2.1.9
IOSLEVEL: 2.2.1.9
VIOS level is | NIM Master level must be equal to or higher than |
---|---|
Update release 2.2.1.9 | AIX 6100-07-10 |
General package notes
Update Release 2.2.1.9 provides updates to Virtual I/O Server (VIOS) which is at least at level 2.2.1.1 and later (2.2.1.x) installations. Applying this package will upgrade the VIOS to the latest level, 2.2.1.9.
Review the list of fixes included in Update Release 2.2.1.9.
To take full advantage of all the functions available in the VIOS on IBM Systems based on POWER6 or POWER7 technology, it is 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 upgrade the VIOS to 2.2.1.9.
Microcode or system firmware downloads for Power Systems
V2.2.1.9 includes the IVM code, but it will not be enabled on HMC-managed systems. V2.2.1.9, like all VIOS Update Releases, can be applied to either HMC-managed or IVM-managed VIOS.
V2.2.1.9 updates your VIOS partition to ioslevel V2.2.1.9. To determine if Update Release 2.2.1.9 is already installed, run the following command from the VIOS command line:
$ ioslevel
If Update Release 2.2.1.9 is installed, the command output is 2.2.1.9.
Known Capabilities and Limitations
The following requirements and limitations apply to Shared Storage Pool (SSP) features and any associated virtual storage enhancements.
Requirements for Shared Storage Pool
- Platforms: Power6 and Power7 only (includes Blades), IBM PureFlex Systems (Power Compute Nodes only)
- System requirements per SSP node:
- Minimum CPU: 1 CPU of guaranteed entitlement
- Minimum memory: 4GB
- Storage requirements per SSP cluster (minimum): 1 fiber-channel attached disk for repository, 10 GB
- At least 1 fiber-channel attached disk for data, 10GB
- All storage devices (repository and pool) should be allocated on Hardware RAIDed storage for redundancy.
Limitations for Shared Storage Pool
Software Installation
- VIOS Software updates must be done while all clients utilizing storage in the Shared Storage Pool are shut down.
- All VIOS nodes must be between version 2.2.1.1 and above.
- When inistalling updates to a VIOS at version 2.2.1.1 and above participating in a Shared Storage Pool, the Shared Storage Pool Services must be stopped.
- The Shared Storage Pool cluster name and the pool name must be less than 16 characters long.
Feature | Min | Max |
---|---|---|
Number of VIOS Nodes in Cluster | 1 | 4 |
Number of Physical Disks in Pool | 1 | 256 |
Number of Virtual Disks (LUs) Mappings in Pool | 1 | 1024 |
Number of Client LPARs per VIOS node | 1 | 40 |
Capacity of Physical Disks in Pool | 10GB | 4TB |
Storage Capacity of Storage Pool | 10GB | 1282TB |
Capacity of a Virtual Disk (LU) in Pool | 1GB | 4TB |
Number of Repository Disks | 1 | 1 |
Maximum number of physical volumes that can be added to or replaced from a pool at one time: 64
Network Configuration
- Uninterrupted network connectivity is required for operation. i.e. The network interface used for Shared Storage Pool configuration must be on a highly reliable network which is not congested.
- Changing the hostname/IP address for a system is not supported when configured in a Shared Storage Pool.
- IPV4 Compliance only
- When a VIOS is configured for a Shared Storage Pool environment, VLAN tagging is not supported.
- A Shared Storage Pool configuration should configure the TCP/IP resolver routine for name resolution to resolve host names locally first, and then use the DNS. For step by step instructions, refer to the TCP/IP name resolution documentation in the AIX Information Center.
- When restoring VIOS LPAR configuration(s) from a viosbr backup, all network devices and configuration(s) must be restored before Shared Storage Pool configurations are restored.
- The system must be configured with the fully qualified domain name. As an example, the hostname command should report the system hostname as mydivision.mycompany.com.
- The hostname/IP address provided for Shared Storage Pool configuration must resolve to the fully qualified domain name.
- The forward and reverse lookup should resolve to the IP address/hostname that is used for Shared Storage Pool configuration.
- It is recommended that the VIOSs that are part of the Shared Storage Pool configuration keep their clocks synchronized.
Storage Configuration
- Uninterrupted access to the repository disk is required for operation.
- Physical Disks in the SAN Storage subsystem assigned to the Shared Storage Pool cannot be resized.
- Virtual SCSI devices provisioned from the Shared Storage Pool may drive higher CPU utilization than the classic Virtual SCSI devices.
- Using SCSI reservations (SCSI Reserve/Release and SCSI-3 Reserve) for fencing physical disks in the Shared Storage pool is not supported.
- High availability SAN solutions should be utilized to mitigate outages.
- SANCOM is not be supported in a Shared Storage Pool environment.
Shared Storage Pool and other VIOS capabilities and limitations
- Virtual SCSI disk is the peripheral device type supported by SSP at this time.
- VIOSs configured for SSP require that Shared Ethernet Adapter(s) (SEA) be setup for Threaded mode (the default mode). SEA in Interrupt Mode is not supported within SSP.
- VIOSs configured for SSP can be used as a Paging Space Partition (PSP), but the storage for the PSP paging spaces must come from logical devices not within a Shared Storage Pool. Using a VIOS SSP logical unit (LU) as an Active Memory Sharing (AMS) paging space or as the suspend/resume file is not supported. Also, Suspend and Resume feature for client LPARs backed by VIOS SSP LUs is not supported.
- When creating Virtual SCSI Adapters for VIOS LPARs, the option "Any client partition can connect" is not supported.
- Suspend/Resume and Remote Restart features for client LPARs backed by VIOS SSP LUs is not supported.
Installation information
Prior to installation
Please ensure that your rootvg contains at least 30GB and that there is at least 4 GB freespace before you attempt to upgrade to VIOS service release 2.2.1.9.
Run the lsvg rootvg command, and ensure there is enough freespace.
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
If you are planning to update a version of VIOS lower than 2.1, you must first migrate your VIOS to VIOS version 2.1.0 using the Migration DVD. After the VIOS is at version 2.1.0, the Fix Pack 2.2.1.1 Release can be applied. Then Service Release can be applied to bring the VIOS to level 2.2.1.9.
After the VIOS migration is complete, from 1.X to 2.X, you must set the Processor Folding attribute, described here under Migration DVD:
Virtual I/O Server support for Power Systems
While the above process is the most straightforward for users, you should note that with this Service Release version 2.2.1.9, a single boot alternative to this multi step process is available to NIM users. NIM users can create a single, merged lpp_source by combining the contents of the Migration DVD with the contents of Fix Pack 25 ( 2.2.1.1 ). Then combine the contents of this Service Release 2.2.1.9 to update.
A single, merged lpp_source is not supported for VIOS that use 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
Before installing the Service Release 2.2.1.9
The update could fail if there is a loaded media repository.
How to check for a loaded media repository, and then unload it
- To check for loaded images, run the following command:
$ lsvopt
The Media column lists any loaded media. - To unload media images, run the following commands on all Virtual Target Devices that have loaded images.
$ unloadopt –vtd <file-backed_virtual_optical_device >
- To verify that all media are unloaded, run the following command again.
$ lsvopt
The command output should show No Media for all VTDs.
Migrate Shared Storage Pool Configuration
If your current VIOS is configured with Shared Storage Pools, you must follow these steps:
The cluster that is created and configured at VIOS Version 2.2.1.1 and above can be migrated to the latest version, i.e., VIOS Version 2.2.1.9. This allows you to keep the shared storage pool devices. If this procedure is not followed and the cluster is running, the update will likely fail.
Note: If you choose to destroy the devices supported by the storage pool, you can delete the cluster and skip these steps; however you will not be able to recover client data, except from existing backups, taken from client partitions.
Please follow these steps.
- On a VIOS at Version 2.2.1.1 or above level, create a backup of the old version cluster as User padmin.
$ viosbr –backup –file oldCluster –clustername clusterA
viosbr command will generate the backup file "oldCluster.clusterA.tar.gz"
- Save the generated backup file oldCluster.clusterA.tar.gz on a different system.
- Close all devices that are mapped to the shared storage pool. This may entail shutting down clients. Complete this step on each node in the cluster.
- Stop cluster services on the node, this has to be done as root. Complete this step on each node in the cluster. For Version 2.2.1.4 and prior, you will need to run the clstartstop command as root.
$ oem_setup_env
# /usr/lib/cluster/clstartstop –stop –n clusterA –m nodeA
# exit - Update VIOS system with Version 2.2.1.9. Refer to the update sections below. Complete this step on each node in the cluster.
Note: The physical volumes used for the storage pool, should remain the same and their contents should not to be altered.
$ updateios –dev [Service Pack images location] –install –accept - After the installation of VIOS Version 2.2.1.9, convert the earlier backup file, created in step 1 to the new format. This generates a migrated backup file, in gz format:
Note: If you came from VIOS Version 2.2.1.4, 2.2.1.5, 2.2.1.6, 2.2.1.7 or 2.2.1.8, then you may skip this step.
$ viosbr –migrate –file oldCluster.clusterA.tar.gz
viosbr –migrate command will create "oldCluster_MIGRATED.clusterA.tar.gz" - Start cluster services on same node as step (6).
$ clstartstop –start –n clusterA –m nodeA
- Restore the database using migrated backup file from step (6).
Note: If you came from VIOS Version 2.2.1.4, 2.2.1.5. 2.2.1.6, 2.2.1.7 or 2.2.1.8, then you may skip this step.
$ viosbr –recoverdb –file oldCluster_MIGRATED.clusterA.tar.gz –clustername clusterA
After successful restore, cluster and all Shared Storage Pool mappings are configured as earlier. - Start cluster services on the remaining nodes in the cluster.
$ clstartstop –start –n clusterA –m nodeB
- Verify if the above cluster restored successfully. List the nodes in the cluster
$ cluster –status –clustername clusterA
- List the storage mappings on the VIOS
$ lsmap –all
Installing the Update Release
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.
To verify the VIOS update files, follow these steps:
$ oem_setup_env
Create a link to openssl
# ln –s /usr/bin/openssl /usr/ios/utils/openssl
Verify the link to openssl was created
# ls –al /usr/ios/utils
# exit
Use one of the following methods to install the latest VIOS Service Release. As with all maintenance, you will want to create a VIOS backup prior to 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.
Applying updates from a local hard disk
To apply the updates from a directory on your local hard disk, follow these steps.
The current level of the VIOS must be between 2.2.1.1 and above
- Log in to the VIOS as the user padmin.
- If you use one or more File Backed Optical Media Repositories, you need to unload media images before you apply the Update Release. See details here.
- If you use Shared Storage Pools, then you must follow specific steps, as outlined under Migrate Shared Storage Pool.
- Create a directory on the Virtual I/O Server.
$ mkdir <directory_name>
- Using ftp, transfer the update file(s) to the directory you created.
- Commit previous updates by running the updateios command
$ updateios –commit
- Verify the updates files that were copied. This step can only be performed if the link to openssl was created.
$ cp <directory_path>/ck_sum.bff /home/padmin
$ chmod 755 /home/padmin/ck_sum.bff
$ ck_sum.bff <directory_path>
If there are missing updates or incomplete downloads, an error message is displayed. - Apply the update by running the updateios command
$ updateios –accept –install –dev <directory_name>
- To load all changes, reboot the VIOS as user padmin .
$ shutdown –restart
- Verify that the update was successful by checking the results of the updateios command and by running the ioslevel command, which should indicate that the ioslevel is now 2.2.1.9.
$ ioslevel
- If you need to restore your clusters database, follow the steps in Migrate Shared Storage Pool Configuration, step 6.
Applying updates from a remotely mounted file system
If the remote file system is to be mounted read-only, follow one of these steps.
The current level of the VIOS must be between 2.2.1.1 and above
- Log in to the VIOS as the user padmin.
- If you use one or more File Backed Optical Media Repositories, you need to unload media images before you apply the Update Release. See details here.
- If you use Shared Storage Pools, then you must follow specific steps, as outlined under Migrate Shared Storage Pool.
- Mount the remote directory onto the Virtual I/O Server.
$ mount remote_machine_name:directory /mnt
- Commit previous updates, by running the updateios command
$ updateios –commit
- Verify the updates files that were copied, this step can only be performed if the link to openssl was created
$ cp <directory_path >/mnt/ck_sum.bff /home/padmin
$ chmod 755 /home/padmin/ck_sum.bff
$ ck_sum.bff <directory_path >
If there are missing updates or incomplete downloads, an error message is displayed. - Apply the update by running the updateios command
$ updateios –accept –install –dev /mnt
- To load all changes, reboot the VIOS as user padmin .
$ shutdown –restart
- Verify that the update was successful by checking the results of the updateios command and by running the ioslevel command, which should indicate that the ioslevel is now 2.2.1.9.
$ ioslevel
- If you need to restore your clusters database, follow the steps in Migrate Shared Storage Pool Configuration, step 6
Performing the necessary tasks after installation
How to check 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 date 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.
How to recover 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:
- Unload any media images
$ unloadopt –vtd <file-backed_virtual_optical_device >
- If you have not yet restarted the VIOS, restart it now. You must restart before you can run the installp command in the next step.
$ shutdown –restart
- 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
To return to the restricted shell:
# exit - Verify that the Media Repository is operational by running this command:
$ lsrep
Additional information
NIM installation information
Using NIM to back up and install the VIOS is supported as follows.
- Always create the SPOT resource directly from the VIOS mksysb image. Do NOT update the SPOT from an LPP_SOURCE.
- To use NIM, ensure that the NIM Master is at the appropriate level to support the VIOS image. Refer to the above table in the "Package information" section.
NOTE: This Service Pack can be combined with Update Release VIOS_2.2.1.1 into the same lpp_source. It is recommended that you run lppmgr, to remove duplicate or redundant packages.
If NIM is not used to update the VIOS, please note that only the updateios command should be used to update it.
Fixes included in this release
APAR | Description |
---|---|
IV51632 | ERASE DISKS OPTION NOT WORKING IN MAINTENANCE BOOT |
IV52116 | GETADDRINFO AND INET_PTON CANNOT HANDLE IPV6 SCOPE/ZONE |
IV53601 | MEMORY LEAK IN CRYPT CAUSING GETPWNAM_R AND CRYPT TO FAIL |
IV58302 | ETHER_ATON DOES NOT VALIDATE THE INPUT AS EXPECTED |
IV58304 | PATHCONF() DOESN'T CLOSE THE FD. |
IV59046 | update bos.alt_disk_install.boot_images |
IV58312 | bosboot fails after rootvg has been migrated to different disk |
IV52395 | SENDER SIDE OF MPING FAILS TO RECEIVE FIRST PACKET. |
IV58348 | CLMIGCHECK COMMAND FAILS DUE TO MPING RC=255. |
IV58350 | CAA: CLMIGCHECK CAN FAIL WITH LARGE NUMBERS OF LUNS |
IV58359 | chrepos removes remote nodes vg |
IV58364 | Security force flag with level 2 doesn't clear the inprogress |
IV58366 | savesecconf command displays wrong certificate type for fixed |
IV58396 | CAA: CLCOMD HANGS WHEN CLUSTER SECURITY CONFIGURED |
IV58412 | Clcomd may hang while under high load |
IV48978 | WRONG RETURN CODE BY LSMCODE FOR UNSUPPORTED DEVICES |
IV50823 | SYSTEM CRASH IN BMINODEFLUSH |
IV52047 | FORKTREE SERIALIZATION ISSUE WITH PINNED PAGES |
IV58191 | KERNEL CRASHES IN AUDIT SUBSYSTEM |
IV58193 | CRASH IN FP_IOCTLX -> GNO_IOCTL() WITH FKERNEL FLAG SET |
IV58194 | SYSTEM CRASH IN VPM_EVAL_STATE() |
IV58195 | crash in mempool rebalancing during dr operations |
IV58200 | CRASH DUE TO LMLOG FUNCTION WHEN LOGSHUTDOWN IS DONE |
IV58208 | Dump failure with Qlogic adaptors. |
IV58498 | TRUSAGE64 CONTEXT SWITCH VALUES ARE RESET AFTER CALLING SYSTEM() |
IV59045 | Potential security issue. |
IV59227 | JFS2 FS MARKED CORRUPT WHEN USING FIND COMMAND NEEDING FSCK RUN |
IV58344 | ISAKMPD LOOPS WITH HIGH CPU AFTER RECEIVING LARGE SCAN PACKET |
IV58358 | ISAKMPD LEAKS AND CRASHES RECEIVING UNKNOWN NOTIFY MESSAGE |
IV55000 | NETWORK PERFORMANCE DEGRADED WHEN SACK IS ENABLED |
IV58294 | File permissions for /etc/rpc now 644 |
IV58398 | FIRST IP ADDRESS IS ALWAYS REMOVED WHEN ALIAS DELETE KEYWORD IS |
IV58403 | FTP WITH -S OPTION DUMPING CORE |
IV58413 | CVE-2013-5211:THE MONLIST FEATURE IN NTPD ALLOWS REMOTE ATTACKS |
IV58736 | PERFSTAT_PARTITION_CONFIG FAILS WITH ERRNO EINVAL |
IV54788 | INCORRECT PMCONF FILE GROUP PERMISSIONS |
IV58353 | TOPAS SHOWS NEGATIVE PERCENTAGE USAGE ON 2G PAGE SYSTEMS(8TB) |
IV54181 | BACKUP BY NAME DOESN'T STOP ON READ ERRORS |
IV51170 | SYSDUMPDEV DOES NOT DISPLAY SIZE WHEN DUMP DEVICE IS CDROM. |
IV58212 | GHOST LVS NOT REMOVED ODM AND DISK OUT OF SYNC |
IV58383 | SHUTDOWN -FR FAILS TO COMPLETE A REBOOT OF THE SYSTEM |
IV58235 | FAULTY DVD MEDIA CAUSES SYSTEM CRASH |
IV58230 | INSTALL.LOG OVERWRITTEN IF UPDATEIOS EXECUTED WITH "-INSTALL" |
IV58234 | TRUSCHK: WRONG /USR/CCS/LIB/.RECOVER/LIBC.A HASHVALUE |
IV58386 | UPDATESD EMGR INSTALL PROCEDURES FOR STACKING CONCURRENT |
IV58728 | TCBCK MAY REPORT FILES ARE WRONG AFTER INSTALLING AN IFIX |
IV45102 | LSPV -U DOES NOT DISPLAY CORRECTLY LONG UDID |
IV45109 | MIGTRATELP FAILS WHEN RUN ON 2ND OR 3RD MIRROR POOL COPY |
IV48755 | EXTENDLV FAILS DUE TO ALLOCP CHOOSING IN-USE PPS |
IV58384 | REPLACEPV MAY FAIL W/ 0516-1232 WHEN DISK WAS PHYSICALLY REMOVED |
IV58385 | CRASH IN HD_BEGIN WITH SYNCVG -F -P OF STRIPED LV |
IV58727 | MIRRORVG MAY NOT ALLOCATE PPS IN THE ORDER OF SPECIFIED PVS |
IV60313 | Potential security issue. |
IV33048 | TRUSTCHK -N TREE COMPLAINS ON SYMBOLIC LINKS TO RELATIVE PATHS |
IV53343 | CRON CAN FAIL IN AN LDAP-CONFIGURED ENVIRONMENT |
IV53700 | CHUSER FAIL TO UPDATE BOOLEAN ATTRIBUTE ON LDAP AD SERVER |
IV54392 | PAM_AUTH ALLOWS USER LOGIN WITHOUT ASKING PASSWORD IT'S NOT NULL |
IV56726 | SECLDAPCLNTD COREDUMP IN MARKSERVERDOWN/_REC_MUTEX_LOC |
IV58375 | MKGROUP IN LDAP LAM FAILS IF "USERNAME" IS MAPPED TO "CN" |
IV58376 | LDAP USERS CAN CIRCUMVENT LOCAL PASSWORD REQUIREMENTS |
IV58378 | AIX system upgrade may hang while applying bos.rte.security |
IV53169 | SYSTEM DUMP TO SECONDARY DUMP DEVICE CAN FAIL. |
IV52152 | SRCMSTR CAN'T START SOME SERVICES SOMETIMES WHILE SYSTEM BOOTS |
IV50279 | PANIC WITH STACK GOING THROUGH PTM_PUT |
IV58343 | BACKUPIOS -FILE COMMAND TO NFS FAILS WITH TAR 0511-188 |
IV60661 | USYSIDENT DIDN'T REPORT THE CORRECT DISK STATUS |
IV53296 | IBM.DRMd may core dump |
IV53313 | HMC CRASHES OR OUTPUTS "CHILD PROCESS RETURNED ERROR" ON THE |
IV55925 | SEA LOAD SHARING FAILOVER NETWORK PROBLEM |
IV58320 | DSI IN VLAN_GET_USER |
IV58415 | FCSTAT -Z CAN BE RUN BY NON-PRIVILEGED USER |
IV58331 | PROBLEMS SVC LUN LEADS TO LONG FAIL TIMES, POSSIBLE SSP |
IV58338 | Possible disk I/O error when using asynchronous storage devices |
IV58425 | Fix system crash risk on rmdev of PCIe3 SAS adapter. |
IV58317 | CAA MKCLUSTER FAILS IF REPOSITORY DISK IS EMC CLARIION/INVISTA |
IV58416 | DSI crash in storfwork:sfwdAddDisk |
IV58271 | Software Error 2B2BF282 when configuring en# interface |
IV58718 | Config Space EEH not detected on configured ent devices |
IV58726 | CCID:2CC0, "Hardware error" in errpt while loading adapter FW |
IV58893 | ifconfig enX fails on 1Gports when speed is set to 1GFullDuplex |
IV51823 | DSI CRASH IN SCSIDISKPIN:POFCMDPROC. |
IV59365 | System crash in pofCheckThread |
IV58244 | LOOPMOUNT CAN CRASH THE SYSTEM |
IV50205 | MULTIPLE GOENT_EEH_ENTRY IS LOGGED WHEN DRIVER IS IN DEAD STATE |
IV58892 | EEH ERROR CAUSES KERNEL PANIC IN NDD_USRREQ(). |
IV46220 | TARGET DROPS TARGET FUNCTIONS: NO FUTURE LOGINS WILL BE ALLOWED |
IV55431 | MPIO hangs when one path suffers a permanent failure. |
IV58321 | NETWORK DOWN AFTER MSNENT_MPIFW_ERR |
IV58248 | SYSTEM CRASH WHILE CLEANING UP RESOURCES IN ELXENT DRIVER |
IV58274 | INCORRECT ELXENT DRIVER TRANSITION STATE FROM DEAD |
IV58322 | DEADLOCK BETWEEN ELXENT_ENTER_LIMBO AND ELXENT_OUTPUT |
IV58722 | adapter with FC 5287 and 1762 Mcast sync fix |
IV58272 | System could crash in response to ioctl SCIOLRESET. |
IV58273 | NPIV IO request times out in protocol driver. |
IV58421 | Paths did not recover after storage side cable moves. |
IV58266 | EEH error after diagnostics is run on 4port 1Gb adapter |
IV58324 | MUSENT_EEH_ENTRY LOGGED WHEN DRIVER IS IN DEAD STATE |
IV58709 | NETWORK PERFORMANCE DEGRADATION ON FC5899 (AUSTIN) ADAPTER |
IV59947 | LPM failing due to error locking source adapter |
IV58909 | cfgmgr can hang at mstor_sleep during error conditions |
IV58446 | SEA NOT FREEING ENTIRE MBUF PACKET CHAIN WHEN VEA MTU MISSMATCH |
IV53419 | Identify LV/VG correctly with serial number during restore |
IV58246 | LSNPORTS DOES NOT LOG DEBUG DATA |
IV58417 | MISLEADING POOL ID REPORTED IN ERRPT ENTRY FOR VIO_ALERT_EVENT |
IV58418 | LSPV -CLUSTERNAME |
IV58422 | May see strange behavior in SSP when cloning LUs |
IV58449 | MIG_VSCI CORE DUMPING WHEN UDID HAS % CHARACTER |
IV58451 | LPM fails when dlpared adapter is in DEFINE state. |
IV60320 | LPM may intermittently fail |
IV61608 | VIOS can crash or hang during LPM to VIOS |
IV51382 | ADD OPTION TO REMOVE HERALD ATTRIBUTE WITH LOGINMSG COMMAND |
IV58292 | User is unable to change the password with passwd -no_int |
IV58352 | IN RARE CONDITION "LSMAP -ALL -NET" MAY GIVE WRONG OUTPUT. |
IV58401 | IOSCLI COMMAND MAY RETURN INVALID RESULT |
IV58405 | REDUCEVG: THE DEFAULT STORAGE POOL "ROOTVG" CAN NOT BE REMOVED |
IV58407 | LSGCL COMMAND DOESN'T DISPLAY VIRTUAL OPTICAL LIBRARY COMMANDS |
IV58408 | PADMIN CAN'T RUN COMMANDS AFTER TOPASREC STOP AND VIOS UPGRADE |
IV58730 | Use SSP DB on system,rather from backup file for cluster restore |
IV47492 | SOURCE MAC OF VIOC TRAFFIC REPLACED WITH REAL ADAPTER MAC ONVIOS |
IV52181 | Potential security issue. |
Was this topic helpful?
Document Information
Modified date:
19 February 2022
UID
hpc1vios4c4c27a