Introducing HP-UX 11i Virtual Partitions

Sep 2007 13
vPars Resources
A typical multi-vPar configuration is created by allocating the available hardware resources on a
hard partition or server to individual vPars. CPU, memory and I/O resources in a server or hard
partition are divided among the multiple vPars.
vPars and CPUs
Each vPar can be assigned CPUs at the CPU-core granularity. The minimum required for a vPar is
a single CPU-core. Depending on the application requirements, you can either pre-assign the
required CPUs at vPar creation time or dynamically add CPUs at run time. Any CPU, except the
monarch CPU of the OS, can be dynamically deleted from a running vPar. CPUs can be assigned
or added/deleted by number (of CPUs), hardware path (of a CPU), or by cell locality.
Since vPars provide a single CPU-core granularity, CPU-cores from a dual-core socket could be
assigned to two different vPars. Even in the case of hyper-threaded CPU-cores, assignment and
migration of CPUs happen at the CPU-core level. Hyper threads (logical processors) of a CPU-core
cannot be split across vPars. When a multi-threaded CPU-core is assigned to a vPar, all threads of
the CPU-core are visible in the OS and the applications running on a vPar can make use of these
logical processors just as in an OS running on a hard partition. When a multi-threaded CPU-core is
deleted from a vPar, all threads of the CPU-core are deleted. Users can also use HP-UX Processor
Set capabilities to enable or disable logical processors inside a vPar.
vPars and Memory
Allocation of memory is specified in configurable blocks of memory (minimum of 64MB). Sharing of
physical memory is not allowed between multiple vPars. The minimum amount of memory that
needs to be assigned to a vPar is the minimum memory required to boot a given HP-UX11i version.
Memory can be assigned or added/deleted by size, address range, or by cell locality.
The memory block size that can be assigned to a vPar is termed the memory granule size. Memory
can be assigned or migrated in multiples of granule size. Memory granularity has to be decided prior
to the vPars database creation. Any change to the memory granularity will require a database
recreation and a hard partition reset.
Starting with the HP-UX Virtual Partitions A.05.01 release, memory can be dynamically added or
deleted from a running vPar. Memory granules in a vPar are classified as base or floating. Memory
assigned or added to a vPar as floating memory can be dynamically deleted from the vPar. Any
memory assigned or added to a vPar without floating attribute is, by default, considered base
memory and cannot be deleted from a running vPar.
vPars and I/O
I/O granularity supported in vPars is at the Local Bus Adapter (LBA) level. vPars requires that each
PCI LBA (top-level PCI bus) is fully assigned to a single vPar. Therefore, the LBAs and the interface
cards attached to those LBAs may not be shared among or split across vPars. This includes multi-
port and multi-function cards.
I/O assignments can only be done when the vPar is inactive (not running).
vPars and Console
The system console on a standalone (non-partitioned) server serves two distinct and unique
purposes. First, the system console is used to monitor and interact with the Guardian Service
Processor (GSP) and Initial System Loader (ISL). Additionally, the system console is used to
monitor and interact with HP-UX, particularly when the system is in single user mode or when
networking or terminal services are unavailable.
With vPars, the system console continues to be used for interacting with GSP and ISL. Individual
vPars use the system console in a multiplexed fashion. When the system console is multiplexed