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.

Date Description
22 July 2020 Linux server fails after Live Guest Relocation (LGR)
Contact IBM Service to install the appropriate bundle.
30 March 2020 APAR VM66219 (PTF UM35465) for VSwitch Priority Queuing is in error.
Apply PTF for APAR VM66363.
20 July 2018 Upcoming required changes to uploading documentation for z/VM problems due to GDPR compliance
30 Mar 2018 APAR VM65943 is in error (PTF UM35187).
Apply PTF for APAR VM66140.
13 Dec 2017 Avoid IPL Failures - Reminder to update the Stand Alone Program Loader (SAPL) for z14  (Updated 10 April 2018)
10 July 2017 APAR VM66026 is in error.
Apply PTF for APAR VM66036.

  • 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

    See related alert in Resource Link.

  • 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.



    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.