Top Ten Tips for Using Virtual Partitions

Introduction
HP-UX Virtual Partitions (vPars) has been available for about six years now. During this time most of
the features and “rules” have not changed. However with more and more customers deploying vPars
especially in a production environment there are implementation considerations. These are often
overlooked when upgrading or expanding existing servers that are already running vPars. These
considerations are mainly in three general areas:
• Performance – since vPars is para-virtualized there are no special considerations for the
performance of a vPar. However, there are configuration issues that do impact the startup and
shutdown of vPars.
• Functionality – functionality here refers more to configuration issues due to the fact that vPars
does not share hardware below the Local Bus Adapter (LBA) level or PCI Slot level. Configuration
of memory and/or granularity also effects functionality.
• Supportability – lastly, HP has set support “rules” which must be followed in order for the
complex configuration to be supported. These “rules” have been determined by the vPar’s
engineering team based on lab tests and code design.
This white paper outlines the ten most common issues in vPar configurations that can lead to problems
in the above categories. For each issue, the most likely symptoms will be listed using these categories
(Performance, Functionality, Supportability).
#1 – Kernel Memory Allocation (HP9000 only)
Symptoms: Performance, Functionality
On PA-RISC, HP-UX has a requirement that a kernel’s text and data must fit within the lower 2GB
address space and must be contiguous. The reason is that some older, more complicated assembly
routines within the kernel perform address manipulation using 32-bit arithmetic. There are no plans to
change this on PA.
This requirement also applies in a Virtual Partition’s environment with the addition that ALL vPars
kernels’ text and data (added together) must fit under the 2GB lower address space and each kernel
must reside in contiguous memory. This restriction usually isn't a problem unless you significantly
increase some of the tunable parameters that affect the data segment. As the vPar monitor is loading
kernels (booting vPars), if one or more of the kernels won’t fit, the load will fail with a message like
this in the monitor log:
INFO:CPU2:MON:No error free contiguous memory in the system to load the kernel below 2GB
Prevention and Suggestions
There are several possible solutions which are documented in the HP Whitepaper titled “How kernel
memory is allocated and may be controlled in a vPars environment”. The best solution is to create
each vPar defining the base and range of memory to be some value that you are sure the kernel will
not grow beyond and make sure the total sum of all the memory allocated to the vPars is less than the
total of the nPar. Please see the whitepaper for the details and example calculations.
#2 – nPars and vPars Mode (Integrity only)
Symptoms: Functionality
On an Integrity system, you must set the mode in order to boot into a specific mode. For
Top Ten Tips for using Virtual Partitions 3 of 8