vparresources2.5 (2012 03)

v
vparresources2(5) vparresources2(5)
(For OA Based Partition Management Systems)
• Multiple nPars must be described in multiple parspecs.
• An 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
NOTE: The keywords
cpu, core, and
CPU-cores are used interchangeably in this document.
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 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 will 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 be added to an
UP/DOWN vPar in one of three ways:
• Non-socket-specific, or generic, assignment,
-a cpu::num or
-a core::num.
num CPU-cores are assigned to the vPar if available. For a DOWN vPar, the system assigns the
reserved 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
vparstatus -v
command shows such CPU-cores as "User assigned".
The CPU-core must be available, that is, it must exist and not 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 for DOWN vPars, cores are reserved, but they are assigned only when the
vPar is booted.
NOTE: When using socket local syntax (socket
:socket_id:cpu::num), for num, only the number of
cores on the given socket may be entered, not the hardware paths of the individual cores.
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.
2 Hewlett-Packard Company − 2 − HP-UX 11i Version 3: March 2012