IBM Support

VM65509: CPU USAGE TIMES DOUBLE COUNTED DURING A RELOCATION

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • A virtual machine's total CPU and virtual CPU usages
    are double counted in the type 1 user accounting record
    after a live guest relocation.  That means there could
    be anomalies in the accounting numbers for a guest
    that gets relocated.  Specifically, the CPU time
    used by the virtual machine from when the previous
    type 1 record was generated until the relocation
    completes is counted on both the source and destination
    systems.
    

Local fix

  • N/A
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All z/VM users of Live Guest Relocation and  *
    *                 accounting records for tracking guest CPU    *
    *                 usage                                        *
    ****************************************************************
    * PROBLEM DESCRIPTION:                                         *
    ****************************************************************
    * RECOMMENDATION: APPLY PTF                                    *
    ****************************************************************
    The fields VMDATTMP, VMDAVTMP, VMDATTMS, and VMDAVTMS are
    wrongly migrated from the source system to the destination
    system during a live guest relocation (LGR).  These fields
    contain the value of each of the respective CPU usage totals
    (VMDTTMP, VMDVTMP, VMDTTMS, and VMDVTMS) when the last
    accounting record was generated.  Each time a type 1 accounting
    record is generated for a user, the differences between the new
    values and the old values are calculated and stored in the
    record as the amount of CPU time used since the last accounting
    record was generated.
    
    This works fine if no live guest relocations occur.  However,
    when a guest is relocated, those fields which contain the CPU
    usage values at generation of the last accounting record are
    passed from the source and restored on the destination.  That is
    what causes the problem.
    
    When the relocation completes, the guest is logged off on the
    source and a type 1 record is generated.  The CPU usage fields
    in the record are filled in with the differences between the new
    values and the last values and included in the accounting on the
    source.  This is the correct thing that should happen.
    
    The problem is that the same CPU usage is now being added to the
    accumulating usage on the destination system because both the
    new and old usage values were migrated during the relocation.
    So the next difference between the old and new values will
    include the CPU usage that occurred on the source.  And now that
    amount of usage has been counted twice.
    
    In addition to this, a type 1 accounting record should not be
    generated on the destination system when a user is relocated
    into that system.  This is not done at logon time and so should
    not be done at relocation-in time either.  Accumulation of CPU
    usage time should start from that point on and be placed in the
    next type 1 record whenever it is generated.
    

Problem conclusion

  • With this fix, the fields containing the CPU usage values at the
    time the last accounting record was generated (VMDATTMP,
    VMDAVTMP, VMDATTMS, VMDAVTMS) are set up on the destination side
    of a live guest relocation with the values in the current usage
    fields (VMDTTMP, VMDVTMP, VMDTTMS, VMDVTMS).  Doing this causes
    the usage that occurred on the source system to be accounted for
    there when the logoff occurs and tracking of the usage on the
    destination system to start with the usage that occurs there.
    Thus the double counting is avoided.
    
    The fix will correct the problem if either the source or the
    destination systems, or both, have the fix applied.
    
    Also, the code that generates a type 1 accounting record on the
    destination system each time a relocation occurs is deleted
    from HCPRLU.
    

Temporary fix

  • FOR RELEASE VM/ESA CP/ESA R620 :
    PREREQ: NONE
    CO-REQ: NONE
    IF-REQ: NONE
    FOR RELEASE VM/ESA CP/ESA R630 :
    PREREQ: NONE
    CO-REQ: NONE
    IF-REQ: NONE
    

Comments

APAR Information

  • APAR number

    VM65509

  • Reported component name

    VM CP

  • Reported component ID

    568411202

  • Reported release

    630

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2014-02-20

  • Closed date

    2014-03-14

  • Last modified date

    2015-02-16

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

    UM34272 UM34273

Modules/Macros

  • HCPRLG   HCPRLU
    

Fix information

  • Fixed component name

    VM CP

  • Fixed component ID

    568411202

Applicable component levels

  • R620 PSY UM34272

       UP14/09/10 P 1401

  • R630 PSY UM34273

       UP15/02/16 P 1501

Fix is available

  • Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.

[{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG27M","label":"APARs - z\/VM environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"630","Edition":"","Line of Business":{"code":"LOB16","label":"Mainframe HW"}}]

Document Information

Modified date:
16 February 2015