HP-UX vPars and Integrity VM V6.3 Administrator Guide

recoverable, local MCAs caused by a CPU in an individual vPar are isolated to that vPar and do
not impact other running vPars.
The vPar OS first tries to automatically recover from such MCAs without bringing down the vPar
(APR supported by HP-UX). If that is not possible, the individual vPar goes through a crash dump
and is rebooted to recover from the error. Diagnostic dump files known as tombstones are
generated. These files must be sent to HP for analysis.
The type of MCAs recovered typically includes user process register file errors, kernel process
register file errors, TLB errors and so on affecting a single vPar. In all other cases of local MCAs
affecting individual vPars or any type of local MCA affecting VSP cores and any global MCAs, a
server or nPartition crash occurs impacting VSP and all vPars. In most cases, a VSP core dump is
also generated. In all cases, MCA logfiles are generated in the standard locations, depending on
the platform.
You must be aware of the following behavior:
• If a CPU core experiences an excessive number of MCAs from which the vPar recovered either
through APR or through rebooting the vPar, system firmware or diagnostics might deconfigure
or deactivate the CPU. In this case, when the vPar reboots, it will not contain a deactivated
or deconfigured CPU core, and the MCA error records belonging to the affected CPU core
might not be available in the /var/tombstones directory.
• If another MCA (of any type) occurs on any other CPU core when recovery of an earlier MCA
is not yet completed, this might cause the server or partition to be reset.
• If you stop or reset a vPar before it completely boots up after processing a local MCA, it might
lead to the server or partition being reset, depending on the platform. On Superdome 2, this
might also result in the nPartition status being displayed as MCA, even though the vPar has
actually recovered from the MCA.
• When a local MCA affecting an individual vPar cannot be contained or isolated, it triggers
a server or nPartiton reset. In most cases, this manifests as an INIT received by the VSP resulting
in a VSP crash dump and reboot. Hence, if there is an unexpected crash of the VSP indicating
a transfer of control, verify the system firmware logs to determine if there was an MCA that
caused this. The VSP crashdump itself might not have any information about the MCA.
5.3 Reserved resources and resource over-commitment
HP-UX vPars and Integrity VM allows the reservation of the resources for VMs and vPars. Reservations
imply that a resource will be available when it is needed, with the assurance that a VM or vPar
can boot at any time.
The reserved resources setting is managed for each individual VM and vPar and is set using the
resources_reserved attribute (managed with the -x option of the hpvmcreate and the
hpvmmodify command). The default behavior of the vparcreate command is to set
resources_reserved to true when a vPar is created. However the hpvmcreate command
does not reserve resources by default when creating VMs or vPars. The resources_reserved
attribute can be managed using the hpvmmodify command. Resources that are reserved include
memory, CPU, and I/O devices. If a resource is assigned to a VM or vPar that has the
resources_reserved = true, that same resource cannot be assigned to a different VM or
vPar that also has resources_reserved = true. It is also not possible to assign a resource
to a vPar or VM that has resources_reserved = true, if that resource is not currently
available.
For example, if all the CPUs have been assigned to other reserving VMs or vPars, then it is not
possible to assign CPUs to any additional reserving VMs or vPars. It is possible to assign resources
to non-reserving VMs and vPars, however, it is not possible to boot them (because the resources
assigned to that VM or vPar are reserved by other VMs or vPars).
5.3 Reserved resources and resource over-commitment 57