HP-UX vPars and Integrity VM V6.1.5 Administrator Guide (5900-2295, April 2013)
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 (/var/opt/hpvm/common/
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 vPar/VM 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:
# ch_rc –a HPVM_MEMORY_OVERHEAD_PERCENT=VALUE /etc/rc.config.d/hpvmconf
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. The default setting is 8. When determining the percentage to set, take the following
into consideration:
• The amount of memory the system has
• The number of guests
• The memory size of those guests the user wants to run
The higher the percentage, the less memory is available for guest use.
NOTE: 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.
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.5 product. Similarly each vPar or VM also has some amount of memory overhead depending
2.5 VSP memory overhead estimation 31