vparresources2.5 (2010 09)

v
vparresources2(5) vparresources2(5)
(For OA Based Partition Management Systems)
attribute for the nPartition.
• When new memory (DIMM) is added to the blades in an nPartition, memory granularity value may get
adjusted by firmware to meet the new memory distribution among the blades. In this case, memory
granularity chosen by firmware is used to round up the memory sizes assigned to individual vPars in
the nPartition. The vPar database is also updated to reflect these memory size adjustments, unless
user has explicitly disabled parspec change policy attribute for the nPartition.
• Memory granularity is applicable even when the nPartition is in nPars mode, though there is no real
use of memory granularity in nPars mode for this release.
Assigning Memory to a vPar
• The
-a mem::size option is used to assign size MB of ILM to a vPar.
• The
-a socket:socket_id :mem::size option assigns size MB of SLM from socket socket_id to a
vPar.
If size is not an integral multiple of the granularity of the specified memory type, vPars normally adjusts
it upward to the next granule boundary.
In a vPar environment, either of the above command line options cause the system to reserve the indi-
cated memory, if it is available. However, actual memory ranges are only assigned to the vPar when it is
booted. These ranges may be different from boot to boot.
I/O Devices
The vPar assignable IO resources are rootports or ioslots in the blades and I/O bays. Rootports and
ioslots have a one-to-one mapping and either of them can be assigned to a vPar. The rootport (RP) or
ioslot is specified in the resource path format. Typically disk devices or LAN devices get attached to a
rootport. On blades, iLO is also off a rootport.
Blades
Blades consist of CPU-cores, memory, and I/O devices. Blades themselves are not vPar assignable
resources. They cannot be added to or deleted from virtual partitions in their entirety. However, CPU-
core, memory and I/O resources on blades can be allocated among different virtual partitions. For exam-
ple, given a blade containing four CPU-cores, one CPU-core can be allocated to each of four virtual parti-
tions, all four to one vPar, or any other possible combination.
Two additional syntax forms allow you to specify that available resources should be allocated from a
specific blade:
•
-a socket:socket_id :cpu::num or -a socket:socket_id :core::num allocates num CPU-
cores on socket_id to the target vPar. The socket_id is specified as enclosure#
/blade# /cpusocket#,
where cpusocket# is the actual socket# .
•
-a socket:socket_id :mem::size allocates size MB (megabytes) SLM from socket_id to the target
vPar. If size is not an integral number of granules, it is first rounded upward to the next integral
value. Whether rounded upward or not, the memory must have been previously configured as SLM by
the parcreate or parmodify commands. See parcreate2 (1M) and parmodify (1M).
I/O Bays
I/O bays are nPartition assignable I/O resources and cannot be added or deleted from virtual partitions in
their entirety. They are located in the I/O expander chassis. Each I/O bay has 6 rootports, which can be
allocated among different virtual partitions.
COMMANDS AND THEIR RESOURCE SPECIFICATIONS
Each vPar can be configured with a subset of total system hardware resources such that any given physi-
cal resource is assigned to at most one vPar. This job is managed by two of the virtual partition com-
mands:
•
vparcreate, used when creating a new vPar. (Resources can only be added)
•
vparmodify, used when modifying an existing vPar configuration. (Resources can be added,
modified, or deleted)
Each command has specific resource syntax and semantic requirements. For example, some syntax forms
can only be specified once.
The general form of a resource specification is up to five positional fields delimited by colons (
:). No whi-
tespace is allowed within any field.
HP-UX 11i Version 3: September 2010 − 5 − Hewlett-Packard Company 5