VIOS 2.2.1.7 FP25_SP05 Contributed by Michael Felt Package information PACKAGE: Update Release 2.2.1.7 IOSLEVEL: 2.2.1.7 VIOS level is NIM Master level must be equal to or higher than Service Pack 05 for Update release 2.2.1.7 AIX 6100-07-07 General package notes The VIOS update Release 2.2.1.7 provides updates to Virtual I/O Server (VIOS) between 2.2.1.1 and 2.2.1.6 installations. Applying this package will upgrade the VIOS to the latest level, V2.2.1.7. Review the list of fixes included in Update Release 2.2.1.7. To take full advantage of all the function 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 V2.2.1.7. Microcode or system firmware downloads for Power Systems The VIOS update Release V2.2.1.7 includes the IVM code, but it will not be enabled on HMC-managed systems. V2.2.1.7, like all VIOS Update Releases, can be applied to either HMC-managed or IVM-managed VIOS. Update Release V2.2.1.7 updates your VIOS partition to ioslevel V2.2.1.7. To determine if Update Release 2.2.1.7 is already installed, run the following command from the VIOS command line: $ ioslevel
If Update Release 2.2.1.7 is installed, the command output is V2.2.1.7 Additional information NIM installation information 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. 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. - Only the updateios command should be used to update the VIOS. For further assistance, refer to the NIM documentation. 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. Fixes included in this release The accumulative list of fixes since 2.2.1.0 APAR Description IV02817 VIOS CRASH WHEN DISABLING SEA ACCOUNTING IV02959
system crash at.compare_and_swaplp+000020 IV04919 CAA panic: ahafs out of buffer IV10273 LU CREATE FAILURE IV15843 clstartstop giving Execute Permission Denied IV18678 PR SHARED TYPE COULD DEFAULT TO THE WRONG VALUE AT CFG TIME IV22571 Double allocation of block during log replay of fileset create. IV23450 Concurrent migration validation fails with Partition ID xx was IV27233 LPM MAY FAIL DUE TO SPECIAL CHARACTERS IN UDID STRING IV27628 MKVDEV LOGS RAS ERROR WITH HYPHENATED LV BACKING DEVICE NAME IV28531 Data Storage Interrupt when running svm driver IV31595 CLCOMD CANNOT COMMUNICATE SOMETIMES IV32048 VIOSBR BACKUP FAILURE FOR ADAPTER WITH DUPLICATE LOC CODE IV32496 VIOSBR "ERROR: ERROR GETTING CUDV FOR VMLIBRARY_LV" IV33916 VIOSECURE FAILS WITH PREREQ FAIL FOR PREREQCDE OF *LS_XHOST RULE IV34507 VEA - INVALID VLAN ID PACKETS FOR VLAN ID > 255 IV35600 ENTRIES IN "TSD.DAT" AND "PRIVCMDS" DO NOT MATCH IV36064 CAA KE LOCK CONTENTION CAUSES NETWORK PERFORMANCE DEGRADATION
IV36138 REDUCEVG HANGS FOR HDISK(SCDISK) WITH DUMP DEVICE IV36390 LSPV DEBUG MESSAGES NOT LOGGED IV36977 CRASH IN TARGET_RAS_UNREGISTER IV36999 ETHCHANPROC HOGS CPU DUE TO PENDING SIGNAL IV37182 LSPV -SIZE DISK ERRORS ON READ-ONLY LUN IV37285 "LSLV -FREE" GIVES RC=1 IF ANY VG IS VARIED OFF. IV37831 Possible I/O error after a path failure IV37928 VIRT OPTICAL DEVICE RESTORE FAILS IF BACKING DEVICE NOT LOADED IV40536 CAA CLCOMD ENCOUNTERS FALSE CONNECTION CONFLICT ERROR IV40544 Potential socket corruption on cluster identity messages IV40551 CLIENT_FAILURE WITH NEWLY CREATED VSCSI CLIENT ADAPTER IV40552 CLIENT HDISK WILL NOT CONFIGURE WHEN MAPPED WITH MIRRORED=TRUE IV40562 Adapters left on VIOS source after moiblity operation. IV40574 System crashed in mpio framework config code. IV40583 Migrations and fail overs fail with reservation conflict. IV40611 ABEND IN GET_ALL_STATS
IV40618 UPDATEIOS MISSING QUOTE WHEN CREATING SHELL COMMAND. IV40619 MBUF LEAK WHEN CAA CLUSTER IS CONFIGURED ON TOP OF A VLANDD IV40627 CLNTOS WRONG IN "LSMAP -NPIV" WHEN CLNTNAME OVER 14 CHARS IV40628 LSMAP WITH -FMT DIDN'T DISPLAY FULL NAME OF CLIENT PARTITION IV40633 CAA must not allow disks using old scdisk device driver IV40635 Crash when using ahafs IV40643 Unable to configure VSN when SEAs' lldpsvc attribute is mixed IV40646 Tx packet drops seen on virtual adapter in VIOS. IV40903 Crash in disk driver when I/O hang is detected. IV40904 TEMP Overlapped Command errors encountered on XIV storage. IV40958 USAGE OF "AGGREGATION" FLAG IN LACPDU (8023AD ETHERCHANNEL) IV41270 MKBDSP WITH DUPLICATE LU_NAME HAS INCORRECT RETURN CODE IV41271 LSMAP MSG "DETERMINING DEVICE TYPE FAILED." WITH VLOG AS BD IV41275 clcomd consumers intermittently fail with slow host resolution IV41585 Possible crash in kexitx after close disk IV41604 LSPV -SIZE DOES NOT WORK FOR SCSI RAID DISKS
IV41918 Display ndd_2_flags in entstat output. IV42122 CRASH IN SCSIDISK_BUILD_ERROR DUE TO UNINITIALIZED CMD STRUCT IV42130 Crash in sfwdprocesssciolevent on recursive lock IV42217 Small possibility of a segfault in cfgscsidisk. IV43138 Cannot get Paging Space from HMC IV43869 lstcpip should not call entstat of interface is not configured 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, 1 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 - 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 SSP Configuration 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. - SChanging 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. - The forward and reverse lookup should resolve to the IP address/hostname that is used for Shared Storage Pool configuration. - 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 will 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/Resume and Remote restart features 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 Pre-installation information and instructions 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.7. Example: Run the lsvg rootvg command, and then ensure there is enough free space. 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.7. 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.7, 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.7 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.7 The update could fail if there is a loaded media repository. Checking for a loaded media repository To check for a loaded media repository, and then unload it, follow these steps. - 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 between VIOS Version 2.2.1.1 and 2.2.1.6 can be migrated to the latest version i.e. VIOS Version 2.2.1.7. 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. If your current VIOS is configured with Shared Storage Pool from 2.2.1.4 or later, the following information applies: 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. - 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. - On a VIOS between Version 2.2.1.1 and 2.2.1.6, create a backup of the old version cluster as User padmin. $ viosbr backup file oldcluster clustername clustera - Save the generated backup file oldcluster.clustera.tar.gz on a different system. - 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.7. 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.7, convert the earlier backup file, created in step 3 to the new format. This generates a migrated backup file, in gz format: Note: If you came from VIOS Version 2.2.1.4 or 2.2.1.5 or 2.2.1.6, then you may skip this step. Example: oldcluster_migrated.clustera.tar.gz $ viosbr migrate file oldcluster.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 or 2.2.1.5 or 2.2.1.6, 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 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. 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 2.2.1.6
- 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 <directory_path>/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 isolevel command, which should indicate that the ioslevel is now 2.2.1.7. $ ioslevel
- If you need to restore your cluster s database, follow the steps in Migrate Shared Storage Pool Configuration. 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 2.2.1.6 - 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 /mnt/ck_sum.bff /home/padmin $ chmod 755 /home/padmin/ck_sum.bff $ ck_sum.bff /mnt 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 isolevel command, which should indicate that the ioslevel is now 2.2.2.2. $ ioslevel - If you need to restore your cluster s database, follow the steps in Migrate Shared Storage Pool Configuration Performing the necessary tasks after installation 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 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. 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:
- 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