vparresources2.5 (2010 09)

v
vparresources2(5) vparresources2(5)
(For OA Based Partition Management Systems)
• Multiple nPars must be described in multiple parspecs.
• A nPartition can be created from a specified parspec.
• Every nPar that exists has a parspec associated with it (referred to as a current parspec), and there
can be only one current parspec for a given nPar.
• Any parspec not associated with an existing nPartition is an alternate parspec.
• Every parspec has a unique name (scope of uniqueness is a complex).
• Parspecs can be managed through the partition commands.
• The vPar database resides within a parspec.
For more details refer to parspec(5) on HP-UX or "Help Parspecs" on OA.
RESOURCES
Different resource types call for different resource management. Each resource type and its management
is described below.
CPU-Cores
The min/max specification: It defines the limits of the number of CPU-cores assigned to a vPar. The
relation:
min
<= total CPU-cores <= max
is always strictly enforced. Although you can modify each value, you will get an error if this relationship
is ever violated, even in mid-command. This means:
• You cannot delete CPU-cores such that new total CPU-cores
< min,
• You cannot add CPU-cores such that new total CPU-cores > max,
• You cannot modify min if that would exceed current total CPU-cores ,
• You cannot modify max to a value less than current total CPU-cores .
If you do not specify min or max when creating a vPar, the following defaults apply:
• min =0.
• max = the total number of active CPU-cores in the underlying nPartition.
For the rest of this section, we assume that any CPU-core operation does not violate a min or a max
requirement.
CPU-cores can only be added to a
DOWN vPar in one of three ways:
• Non-socket-specific, or generic, assignment,
-a cpu::num or -a core:
num. num CPU-cores are
allocated to the vPar if available, but the system assigns specific CPU-cores only when the vPar is
booted.
• Specific assignment by resource path,
-a cpu:cpu_path or -a core:
core_path. If this operation
succeeds, the specified CPU- core is assigned to the vPar. The CPU-core is permanently associated
with the vPar unless it is deleted by resource path,
-d cpu:
cpu_path or -d core:core_path. The
vparstatus -v command shows such CPU-cores as "User assigned".
The CPU-core must be available, that is, it must exist and not be have already been reserved to either
this or another vPar.
Hewlett-Packard recommends that users configure specific CPU-cores only when required for perfor-
mance, and that you do not mix user-assigned CPU-cores and Socket Local Processors (next bullet) in
the same vPar database. Where performance is not a consideration, specify only generic assignments
and allow the system to manage assignment of CPU-cores.
• Assignment by specifying a socket,
-a socket:socket_id :cpu::num or -a
socket:socket_id :core::num. The system is free to assign any num available CPU-cores from
socket socket_id . CPU-cores assigned in this way are referred to as Socket Local Processors (SLP) .
As with generic assignment, they are allocated, but specific CPU-cores are only assigned when the
vPar is booted.
Hewlett-Packard recommends that users configure SLPs only when required for performance, and
that you do not mix SLPs and user-assigned CPU-cores (previous bullet) in the same vPar database.
Where performance is not a consideration, specify only generic assignments and allow the system to
manage assignment of CPU-cores.
Any CPU-core assigned to a vPar can be deleted the same way it was assigned. For example, if you have
configured a vPar as follows:
2 Hewlett-Packard Company − 2 − HP-UX 11i Version 3: September 2010