3.1 An Introduction to Virtual Partitions

     

A Virtual Partition (vPar) is an independent instance of an Operating System running on a subset of hardware components taken from an existing server or Node Partition. Each Operating System instance runs completely independently of other instances, and as such, a primary reason for using vPars is to offer application and Operating System software fault isolation. Additional benefits include:

• Increased system utilization by partitioning previously unused portions of the server. Typically, a non-vPars server is only using 50 percent of its capacity.

• Greater flexibility of resources through:

  - Multiple but independent operating environments per server (with as low as one CPU granularity per partition)

  - The dynamic movement of CPU power between virtual partitions depending on workload requirements.

• Increased isolation of applications, their operating systems, and assigned resources (CPU, memory, and I/O) with individual reconfiguration and rebooting of the individual partitions without affecting other partitions and their applications.

• Increased product integration with other HP-UX offerings that includes iCOD, Partition Manager, Online Diagnostics, and Virtual Partition Manager.

Currently, we cannot dynamically add memory to a vPar without rebooting it. While performance is one criterion, security may be another with each vPar being isolated from other partitions on the system. Virtual partitions are implemented as a software solution. Initially we take an existing installation of HP-UX and install the Virtual Partition software. We then define the number of Virtual Partitions we require in the Virtual Partition Database ( /stand/vpdb ) using commands such as vparcreate (or via the vparmgr GUI). At system boot time, the Virtual Partition Monitor ( /stand/vpmon ) is executed instead of the normal HP-UX kernel /stand/vmunix . The vpmon reads the Virtual Partition Database ( vpdb ), which details the hardware components belonging to respective vPars. The vpmon then boots the appropriate HP-UX kernel located on a boot disk within each vPar (Figure 3-1).

Figure 3-1. How vPars work

The console interface for the original server/nPar is used to manage all vPars. By using the key sequence ctrl-a , the administrator can switch between the virtual consoles for each vPar.

To make my life easy, I simply visualize a Virtual Partition as a minimal server configuration:

• At least 1 CPU

• The minimum amount of memory to support HP-UX

• IO capability to support a boot device

• A LAN card (probably) to support networking

Most vPar solutions will use 1GB of memory per active CPU. Technically this is not an absolute requirement; it just seems to work better. What we need to do is to work out how many vPars we need to configure based on our application/ user needs as well as some limitations imposed by the vPar software (check the documentation Installing and Managing HP-UX Virtual Partitions (vPars) available at http://docs.hp.com/hpux/pdf/T1335-90018.html for server specific limitations as to the maximum supported number of Virtual Partitions).

In reality, we need to consider other criteria as well as the number of vPars to consider. Other considerations include:

• Will we want to configure multiple paths to IO devices? If so, this will limit the overall number of IO devices available to vPars.

• Will we want to configure floating CPUs? A floating CPU is known as an unbound CPU. This has limitations as to what the CPU can process, i.e., unbound CPUs do not process IO interrupts. These limitations are offset by the ability of unbound CPUs to be added and removed to existing vPars without requiring a reboot. Consequently, the overall number of CPUs available to the initial vPar configuration may be considerably less, as we may want to configure a pool of unbound CPUs in order to allocate them as we see fit.

• Applications that perform a significant amount of IO will need to be configured with more bound CPUs. Unbound CPUs do not process IO interrupts. This can affect the number of floating CPUs in your overall vPar configuration.

IMPORTANT

Be sure that you understand the difference between a bound and an unbound CPU. Also be sure that you understand the differences in respect to the IO processing performed by each. This can impact your overall partition configuration in light of the IO requirements of each partition/application.