z/VM Service: Red Alerts
This page is intended to provide information about potential high-impact items and in some cases prior to the opening of an APAR. Note that when a release level reaches the end of service, we intend to remove the item from the list.
19 September 2022
The z/VM 7.3 RAMDISK system will configure less storage than specified in the LPAR activation profile during a first level z/VM installation.
z/VM 7.3 users who install z/VM 7.3 first level in an LPAR configured with more than 2G initial storage in the LPAR activation profile during z/VM installation
After a first level installation of z/VM 7.3 is performed, when any system is IPLed in the same LPAR where the installation was performed, users who configure more than 2G initial storage in the LPAR activation profile will observe only 2G of storage configured for their system. The remainder of the initial storage specified in the activation profile, less the 2G already configured, will be added as STANDBY storage to the LPAR. For example, if the LPAR activation profile configures 10G of storage with 100G reserved storage, z/VM will show 2G configured storage with 108G configured as STANDBY. This storage configuration will persist until z/VM (or another guest OS that is IPL'd in the partition) modifies the storage definition, or until the logical partition is de-activated and re-activated.
This behavior is the result of the installation RAMDISK system reconfiguring storage to use only 2G of storage while the installation is being performed, and the rest offline.
There are two options for resolving this problem:
- Issue a CP SET STORAGE command specifying a value equivalent to the activation profile value for initial configured storage. For the example described above of 10G initial and 100G reserved storage, the command would be CP SET STORAGE PERM 10G. This command should be issued before the RAMDISK system is shutdown.
- De-activate and re-active the z/VM partition after shutting down the RAMDISK system, but before IPLing a subsequent system.
01 July 2021
APAR VM66173 (PTF UM35834) for 4TB REAL MEMORY SUPPORT is in error
z/VM 7.2.0 users applying PTF UM35834 for APAR VM66173 4TB REAL MEMORY SUPPORT may experience various guest I/O errors.
Note that the PTF for VM66173 was NOT part of the 7202 RSU that shipped March 31, 2021.
Users running this environment may see I/O error messages on the z/VM OPERATOR's console, such as:
- HCPERP602I DASD 30B2 AN INTERFACE CONTROL CHECK OCCURRED
- HCPERP6303I SENSE = INVALID
- HCPERP6304I IRB = 84C24017 16918C50 00020000 0010E480
- HCPERP6305I USERID = BITTEST
- HCPERP2216I CHANNEL PATH ID = 75
- HCPERP2220I PHYSICAL CHANNEL PATH ID = 0214
Messages like these may also be seen:
- HCPERP6312I DASD 3066 AN OPERATION WAS TERMINATED BECAUSE A CHANNEL PROTECTION CHECK OCCURRED
Error messages on z/OS guests may also be seen, such as:
- IOS050I CHANNEL DETECTED ERROR ON 1411,1B,92,**02
- IEA306I 1411,1B, I/O ERROR, 92,0E00,0008,VSMPTS
- IEA011A RESPECIFY ENTIRE IEASYMXX SUFFIX LIST OR U TO BYPASS
The z/VM system does not abend. The likelihood of experiencing these errors is significantly higher in environments running z/OS guests.
Apply PTF UM35556 for APAR VM66289 as soon as possible.
22 March 2021
RACF users applying VM66173 (PTF UM35834) will encounter VMSES/E errors - Fixing PTF now available
z/VM 7.2.0 users applying this PTF for 4TB REAL MEMORY SUPPORT will encounter VMSES/E errors if they are using RACF as their External Security Manager.
When applying this PTF, the SERVICE command produces several VMSES/E error messages, including:
- VMFAPP2120W Part HCPRPP TXT has service at level VVTRPI which is a higher level than VVTVM. The higher-level service may need to be reworked or removed
- VMFSUI2308W Part HCPRPP TXT has a local modification 99999 in version vector VVTRPI which must be reworked prior to building product 7VMCPR20%CP
- VMFSUI1206W Service was not built for product 7VMCPR20%CP because local modifications or customized parts needing rework have been identified for this product
- VMFSUI2760W VMFSUFIN processing incomplete due to local modifications or customized parts
- VMFSRV2310W Program restart file, SERVICE $RESTART, has been created or persists due to local modifications. Rework the local modifications, then restart SERVICE using the command that follows: SERVICE RESTART
- VMFSRV2760W SERVICE processing incomplete due to local modifications or customized parts.
In general, the above messages are intended to alert a system programmer that a local modification needs to be reworked because of intersection with the PTF being applied. In this particular case, the local modification references a part used by IBM RACF, and there is no rework required.
Do the following on the MAINT720 user ID to mark the rework as complete:
- Enter the command VMFUPDAT SYSLMOD to display the SYSLMOD Update Panel.
- On the panel, locate the local mod record for the CP part HCPRPP TXT. In the "AC" column for that line, change the code to "C" to indicate the rework for the local mod is COMPLETED.
- Press PF5 to process the SYSLMOD update.
- Restart SERVICE processing by issuing SERVICE RESTART.
June 2021 update:
IBM has provided an update to have VMSES/E automatically handle this scenario without the user needing to perform the steps above. This change to VMSES/E is APAR VM66508 and is available as PTF UM35859.
July 22, 2020
Linux server fails after Live Guest Relocation (LGR)
All z/VM users (any service level) using Live Guest Relocation with old versions of Linux on z13, z14, z15, and LinuxONE servers where SMT-2 is set for z/VM.
Linux levels affected: equal to or older than SLES11, RHEL6, or equivalent. Newer levels of Linux are not affected. Refer to Linux on IBM Z for details on certified Linux levels per Z platform.
Users might experience Linux server failure after performing LGR. More current levels of Linux are not exposed to the problem. The cause of the issue occurs during Linux startup when running on an affected machine with SMT-2 active for z/VM. A memory control bit might be improperly cleared by hardware millicode. Later, this bit setting can result in a page of zeros in Linux low storage after LGR. This can result in various failures in Linux depending on the page affected, and the errors do not always surface immediately after relocation.
Contact IBM Service to install the appropriate bundle. Then LOGOFF/LOGON or re-IPL (with CLEAR option) any affected Linux guests before attempting LGR. This will ensure all memory control bits are properly set.
CAUTION: If IPL is used instead of LOGOFF/LOGON, the IPL CLEAR option is required (and is NOT the default) to ensure all memory control bits are properly set. IPL commands embedded in restart scripts might not include the required CLEAR option.
Available corrective service levels:
z15: Driver D41C Bundle S25
z14: Driver D36C Bundle S39
z13: Driver D27I Bundle S96
March 30, 2020
APAR VM66219 (PTF UM35465) for VSwitch Priority Queuing is in error. This can cause hung guests and/or SXA004 abends.
z/VM 7.1 users with PTF UM35465 applied.
In rare cases, users might experience hanging guests and/or SXA004 abends when using VSWITCH-related functions.
Apply VM66363 (PTF UM35608) as soon as possible. For more information, go to the IBM Security Portal.
July 20, 2018
Upcoming changes to uploading documentation for z/VM problems due to GDPR (Global Data Privacy Regulations) compliance
All users that upload problem related documentation to IBM using the ECuRep or Boulder testcase servers.
At a future date yet to be announced, for GDPR compliance, all uploads of documentation to either the IBM Boulder testcase or ECuRep servers will require an IBM Support File Transfer ID and password (token), and must use a secure transport protocol, such as FTPS. Unsecured FTP will be eliminated. For more details, including what specific things z/VM Customers must do comply, click here.
Mar 13, 2018
APAR VM66140 should be applied for clients deploying non-fullpack minidisks on EAV DASD
All Users that deploy non-fullpack minidisks on 3390 model A DASD greater than 65520 cylinders.
In certain situations, formatting of a minidisk on an EAV volume fails to properly format real cylinder 65535. The formatting program will appear to work so the bug is not obvious at that time. This can result in other applications or middleware failing when it attempts to use that cylinder, and failing in a way that might appear to be a hardware error.
This bug has been discovered in Full Function CCW translation for minidisks. This occurs when a DEFINE EXTENT (or PREFIX) CCW contains cylinder value 65535 (xFFFF) in the Start or End cylinder field, after conversion of virtual cylinder values to real cylinder values. The most prevalent use case to produce this situation is if a VM minidisk starts or ends on real cylinder 65535 (e.g., MDISK 3390 65535 5). However, any minidisk that spans real cylinder 65535 in theory could hit the problem. The result is that command chaining is turned off and the rest of the channel program is not executed. No I/O error is usually produced, so the fact that no data is read or written can go unnoticed.
To validate the cylinder in question, one could use DDR TYPE, DITTO VIEW, or similar functions to view raw track data and verify if the virtual tracks corresponding to real cylinder 65535 has been properly formatted and contain reasonable data contents. A successful file level copy to a different disk could also give reasonable assurance that the problem didn't occur. Use of DDR or Flashcopy to move the contents is not a solution as that could also copy the bad cylinder.
All Users with 6.4 EAV Minidisk Support APAR VM65943 (PTF UM35187) should apply this APAR, but the root cause exists in base code. However, it was much harder to hit this problem prior to VM65943 because non-fullpack minidisks could not start above or span real cylinder 65519, the highest cylinder for a mod-54. Given that the great majority of channel programs are written with Define Extent boundaries that cover the entire virtual disk, it is highly unlikely that the issue will have occurred unless the Start or End cylinder of the minidisk is real cylinder 65535. 65535 is at play here because it historically was used to force errors since no valid real cylinder existed at that location. The introduction of EAV devices, by definition a DASD with greater than 65520 cylinders, made that cylinder location valid.
Apply APAR VM66140 (PTF UM35296)
Dec 13, 2017
(Updated April 10, 2018 to correct which APAR in base vs. RSU)
Avoid IPL Failures - Reminder to update the Stand Alone Program Loader (SAPL) for z14
If you are considering upgrading your hardware to a z14, you must read, understand, and comply with all of the text included in these APARs to avoid z/VM IPL problems:
- VM65942 - z/VM support for z14 with driver D/T3906
- VM65856 - ESA/390 Removal Support for z/VM V630
All z/VM Users planning to migrate to z14
If you do not upgrade SAPL as instructed, you will not be able to IPL z/VM on the z14. Customers are urged to upgrade SAPL as instructed immediately because it is very difficult to do this once the z14 is installed.
Both VM65856 and VM65942 are required for either 6.4.0 or 6.3.0 (out of service). VM65856 is included in the base of z/VM 6.4.0. VM65942 is on the 1702 RSU for z/VM 6.4.0 but can be ordered and applied separately. For both 6.3.0 and 6.4.0 releases, this is a reminder that there are MANUAL STEPS that MUST be performed in order for you to IPL z/VM on a z14. In particular, the steps for upgrading SAPL are critical to the operation of your system and must not be skipped. These steps are referenced in the APARs above, and for 6.4.0 users in the "Post upgrade installation" section of the 6.4.0 Installation Guide manual. For 6.4.0 users, here is the step from the 6.4.0 Installation Guide:
"Changes made to the Stand Alone Program Loader in z/VM 6.4.0 require that the SALIPL record be rewritten to the IPL volume. Rewrite your SALIPL record using the z/VM 6.4.0 level of the SALIPL MODULE. See Chapter 2, "Using the Stand-Alone Program Loader", in z/VM System Operation 6.4 for instructions on rewriting the SALIPL record."
For 6.3.0 users, VM65942 says that you must install SAPL with the updated SALIPL provided by the PTF for APAR VM65856. For instructions on installing SAPL, refer to Chapter 2 of the z/VM System Operation 6.3 manual.
July 10, 2017
APAR VM66026 is in error. See problem resolution.
Do not apply the PTF for "VM66026 MONITOR ENHANCEMENTS FOR HYPERPAV / PAV AND ZHPF."
All users of HyperPAV and zHPF
It might cause serious problems if you are using system-attached HyperPAV / PAV alias devices. This APAR closed on June 7, 2017 and is NOT on an RSU. "VM66036 PEVM66026 ABENDPRG006 ON SYSTEM ATTACHED ALIAS I/O" has been opened to fix this, and the fix is in our internal test phase.
These alias devices can be attached to the system with either the SYSTEM_ALIAS configuration statement in SYSTEM CONFIG, or the CP ATTACH command.
Apply PTF for APAR VM66036
Do you want to be notified when this page changes? Click on Notify Me in the left-hand column and complete the form to receive a notice when this page changes.