A fix is available
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
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