HP vPars and Integrity Virtual Machines V6.1 Administrator Guide

The Integrity VM product, on startup, reserves a significant portion of the free system memory
available on the VSP for the vPar/VM memory pool. The memory left as available in the VSP is
sufficient for the optimal functioning of the vPars and Integrity VM product functionality and features
on the VSP.
Typically, about 92% of free memory available at the Integrity VM product start time (after HP-UX
has booted up on the VSP) is reserved for the vPar/VM memory pool. The amount reserved also
depends on the total system memory and the total number of system cores. On a small memory
system (32G or less), you would find that a lower percentage of system memory is reserved for
the vPar/VM memory pool;, whereas on a large memory system, you would find that a higher
percentage is reserved for the vPar/VM pool. Use the hpvmhwmgmt -p memory -l command
to display the allocation of memory. The command.log also has information about the free memory
available when the vPar/VM memory pool was allocated.
Note that only 64MB or larger contiguous chunks of memory is reserved for the vPar/VM memory
pool, and therefore, the system memory fragmentation at Integrity VM product start time affects
the amount of memory that can be reserved for the vPar/VM memory pool. If the Integrity VM
product is stopped and is restarted only after a long time, it is possible that there is not enough
64MB or more contiguous memory ranges in the VSP to match the memory that was reserved for
vPar/VM pool previously. This can lead to an over-commitment of the memory assigned to the VMs
or vPars.
NOTE: HP strongly recommends that you restart the VSP when the Integrity VM product needs
to be restarted so that system memory fragmentation impacts on vPar/VM memory pool size can
be minimized. There is still a chance of not being able to get the exact same amount of memory
reserved earlier for the vPa/VMr pool leading to an over-commitment. This situation would be very
rare, but not impossible. In that event, memory assigned to an individual VM or vPar needs to be
adjusted to come out of the overcommitted state.
Memory availability for VSP use can be controlled using the HPVM_MEMORY_OVERHEAD_PERCENT
configuration variable. If this variable is set to an appropriate value in the hpvmconf file, that
value is used to determine the amount of memory reserved for vPar/VM the memory pool. For
example, if HPVM_MEMORY_OVERHEAD_PERCENT is set to N, then (100-N)% of free system memory
available at Integrity VM product start time (after HP-UX has booted up on the VSP) is reserved for
the vPar/VM memory pool. Note that a VSP restart (or Integrity VM product restart) is required for
this change to take effect. HP strongly recommends that customers do not use this configuration
variable to change VSP memory availability unless otherwise documented or recommended by HP
field personnel.
2.5 VSP memory overhead estimation
As explained earlier, VSP requires some amount of memory for the optimal functioning of the V6.1
product. Similarly each vPar or VM also has some amount of memory overhead depending on the
size of the vPar or VM. Given below is a rough estimate of the memory overhead required for the
VSP as well as individual vPars and VMs.
The vPar/VM memory pool reserved is roughly about 92% of the system free memory available
at the time of V6.1 product startup. The remaining memory is left out as free memory available for
VSP use. This is in addition to the memory taken up by HP-UX to boot on the VSP. The memory
taken up by HP-UX to boot depends on the size of the system, including total memory, number of
cores and the I/O devices on the system. So the overall VSP memory overhead is the sum of the
memory HP-UX needs to boot up on the system plus the free memory left in the VSP for optimal
functioning of the VSP. In terms of overall system memory, the VSP memory overhead typically
equates roughly to 1500MB + 8.5% of the total physical memory.
Note that the calculation for how much memory is in VSP versus what is available for vPars and
VMS is done at product start time. You can see the hpvmhwmgmt –p memory –l output to see
how much memory is available for vPar/VM memory pool size.
2.5 VSP memory overhead estimation 31