HP vPars and Integrity Virtual Machines V6.1 Administrator Guide

not visible to HPUX commands in the VSP. In V6.1, all the non-VSP cores are visible to the VSP.
When vPars are started, these cores are deallocated from the VSP.
A single VSP core can service vPar management requests and moderate to heavy I/O loads. When
the VSP core becomes saturated, the response time of vPar commands and other applications
being run on the VSP might increase. If the CPU saturation makes the response time of the vPar
commands intolerable, use the vparhwmgmt command to increase the core count in the VSP. You
can modify the VSP core count to a value greater than one, if additional processing power is
required to support high I/O workloads or a large configuration such as BL890c i2. You can use
performance tools such as Glance and Top to determine the CPU utilization of the VSP.
The sum of the VSP and vPar core counts cannot exceed the number of cores on the system. Hence,
any adjustment you make to the VSP core count will affect the cores available to the vPars. While
adjusting the VSP core count, if you exceed the system core count, and if the vPars are already
configured, an error occurs. In such a situation, to satisfy the core count required for the VSP, first
adjust the core count of one or more vPars using the vparmodify command, then adjust the VSP
CPU core count using the vparhwmgmt command.
IMPORTANT: If the system is brought down due to a faulty CPU core and the cores are
deconfigured, then the vPars might not boot during the subsequent boot of the VSP. This is possible
if the sum of the remaining cores is less than the sum of the cores allocated to the VSP and vPars
as displayed from the vparhwmgmt command. You can clear this condition by removing the cores
from the vPars or VSP to meet the configuration requirements.
For example, the VSP has one core allocated to it and the vPars has the remaining seven cores,
and a core is deconfigured as it has a hardware issue. After you boot the VSP, none of the vPars
are bootable until the number of cores assigned to the vPars is reduced by the number of
deconfigured cores. In this case, you must reduce the CPU count of one of the vPars by one.
2.3.2 VM environment
As in Integrity VM V6.1 environment, there is no requirement for a dedicated VSP core. By default,
there are no dedicated VSP cores. All the cores on the VSP are in the vPar/VM pool and are shared
by the guests. However, you can configure dedicated cores in the VSP, if there is a need, using
the hpvmhwmgmt command, but that is not required or recommended in a VM-only environment.
IMPORTANT: If the system is brought down due to a faulty CPU core and the cores are
deconfigured, some of the VMs might not boot during the subsequent boot of the VSP. You might
have to reduce the number of vCPUs of the affected VMs and/or reduce the overall CPU entitlement
for all the VMs to boot the affected VMs.
2.3.3 Default cores after installing V6.1
If there are no existing VM or vPar configurations on the VSP (for example, a brand new installation),
then you will see that the cores reserved/allocated for the VSP is zero by default. If there are
existing vPar configurations (for example, upgrading an existing vPar V6.0 system), you will see
that the cores reserved for VSP is non-zero. If there are existing VM configurations (for example,
upgrading an existing VM V4.3 system), you will see that the cores reserved for the VSP is zero,
matching the Integrity VM Host in a V4.3 environment.
2.4 VSP memory
As mentioned in other sections, the VSP has a controlled environment tuned for supporting the
vPars and Integrity VM V6.1 product functionality. This applies to memory availability in the VSP
too. HP strongly discourages running of customer applications or other workloads on the VSP,
because this might affect the memory availability for the optimal functioning of vPars and Integrity
VM product.
30 Installing and configuring VSP for HP-UX vPars and Integrity VM V6.1