HP supports two different
virtual partitioning options: Virtual Partitions and Integrity Virtual
Machines. Key Features
Virtual Partitions
(vPars) effectively provides you with the ability to run multiple copies
of HP-UX on a single set of hardware, which can be a system or an nPar.
It provides the ability to allocate CPUs and memory and I/O card slots
to each of your OS images. Once that is done, the partitions boot as if
they are separate systems.
Functionality
The key features of vPars include:
Single CPU granularity:
Each vPar can have as little as one CPU. Two CPUs are
recommended for the same reason you want to have two of anything
else—high availability—but that is not required.
Dynamic reassignment of CPUs across virtual partitions:
CPUs can be deallocated and allocated between partitions while
they are up and running. This makes it possible to increase the
utilization of the system by allowing unused CPUs in one partition to be
moved to a partition that can use them.
Application and OS isolation:
Each vPar runs its own copy of HP-UX. This ensures that each
partition is fully isolated from all others. This includes application,
namespace, OS, and kernel isolation. Each partition can be updated,
patched, tuned, and rebooted independently.
Both graphical user interface (GUI) and command-line-configuration interface:
The primary interface for configuring vPars is using the
command-line tools. However, the VSE Manager toolset will provide a
graphical view of vPars in the context of the servers and nPars they are
running in. You will also be able to get configuration and resource
usage information from this interface.
Integration with Process Resource Manager (PRM), Workload Manager (WLM), and GlancePlus:
All the major management tools operate appropriately with vPars.
PRM can run inside vPars, allowing you to further partition your
server. WLM automates the allocation of resources to resource partitions
inside and across vPars. GlancePlus runs normally inside a vPar.
System and OS Support
The vPars product has
been available since 2001. It supports the rp5405, rp5470, rp7400 and
all of HP's cell-based servers. There are some limitations with the
cards and systems supported, and these are changing regularly, so you
should verify that the configuration you are considering is supported
with the current vPars software.
Architecture
This section will provide some insights into the architecture of the vPars product.
Overview
vPars runs on top of a lightweight kernel called the vPar Monitor. The high-level architecture is shown in Figure 1.
Some interesting things to note in this figure include:
The vPar monitor:
Instead of booting the system or nPar to HP-UX, you boot what is
called the vPar monitor. The monitor is configured to know what
partitions should be running on this system and which hardware
components belong to each partition.
The vPars:
The monitor boots the partitions to HP-UX. When the OS queries
the hardware to determine what components are available, the monitor
traps those firmware calls and responds with only the components that
particular partition is supposed to be able to see. The OS boots
normally and simply appears to be a smaller system. Each OS can be
separately patched, tuned, and booted.
The Applications:
Once the vPar is running, the only communication between the
partitions is through the network via the network interface cards
assigned to each partition. It appears to the applications as if they
are running on a separate physical system.
Partitionable Resources
In order to decide how to divide up a system, the first step is to do an ioscan to map out the resources that are available. The ioscan will provide all the information you need to identify which resources are available for assignment to vPars.
note
It is important that you run the ioscan
and save or print the output prior to configuring and booting your
first vPar. This is because once the monitor is running, the only access
to the command will be from a running vPar and running ioscan
from a vPar will only show you the available resources in that vPar.
This means that you won't be able to identify the resources that can be
assigned to other vPars. Actually, you will be able to identify the
existence of I/O cards using the 'vparstatus –A' command, but there will be no information about what types of cards they are.
Figure 2 shows the resources available on an rp7400 graphically.
There are a few key things to understand about this diagram before you decide how to partition this system.
Partitioning CPUs
On older versions of vPars, there was the concept of bound vs. unbound processors. The distinction is this:
An important distinction
with the bound processors is that the actual I/O activity could be
handled by any of the processors; only the interrupts were handled by
the bound processors. On these older versions, each vPar needs to have
at least one bound processor, but it may benefit from more, depending on
the amount of I/O interrupt handling required by the workloads running
in the vPar.
Version 4.1 of vPars
resolved this issue. HP-UX version 11iV2 now supports the movement of
I/O interrupts between processors, so there is no longer any need for
bound processors. You still need at least one processor if you want to
keep the vPar running, of course. Other than that, all the CPUs can
freely move between vPars.
Partitioning Memory
Memory is allocated to
vPars in 64MB ranges. It is possible to specify the blocks of memory you
want to allocate to each of the vPars, but this isn't required. The
memory controller (block 192 in Figure 2-12)
is owned by the vPar monitor, which allocates the memory to the vPars
when they boot. Changing the memory configuration of a vPar currently
requires that the vPar be shut down, reconfigured, and then rebooted.
Partitioning I/O Devices
I/O devices are
broken up into system bus adapters (SBAs) and local bus adapters (LBAs).
The SBAs are owned by the vPar monitor. I/O devices are assigned to
vPars at the LBA or SBA level. On HP systems, the LBA is equivalent to
an I/O card slot. Each SBA or LBA can be assigned to a specific vPar.
Whatever card is in that slot becomes owned by that vPar and will show
up in an ioscan once that vPar is booted.
Keep in mind that if the card is a multifunction or multiport card,
then all the ports must be assigned to the same vPar.
Changing the I/O slot
configuration of a vPar requires that the vPar be shut down,
reconfigured, and then rebooted. A couple of interesting points on this:
HP-UX and
vPars supports hot swappable I/O cards. What this means is that you can
physically pull a card out of a slot in one vPar and insert it into a
slot in another vPar while both vPars are up and running if the
appropriate drivers are available in both kernels. You will not want to
do this often, but it might be useful for devices that are rarely used,
such as CD drives, where you need to go to the device anyway.
You
can, and probably should, allocate one or more of your unused card
slots to each of your vPars to allow for future upgrades without
requiring a reboot.
Security Considerations
In order to make it
possible to administer vPars from any of the partitions, the early
versions of the vPar commands were accessible from any of the
partitions. These include the vparmodify, vparboot, and vparreset
commands. On the positive side, a root user in any of the partitions can
repair the vPar configuration database. The tradeoff was that it was
possible for a root user in another partition to shut down, reboot, or
damage another partition configuration. Newer versions of vPars will
resolve this issue by allowing you to assign each vPar the designation
of being a Primary or a Secondary administration domain. When these
commands are run in a vPar that is a Primary administration domain, they
will work as they did before. However, when running these commands in a
vPar that is a Secondary administration domain, they will only allow
you to operate on the vPar the command is run in. In other words, you
will be able to run a vparmodify command to alter the configuration of
the local vPar, but if you attempt to modify the configuration of
another vPar, the command will fail.
We do need to
clear up one common misconception about this security concern, though.
Each partition runs a completely independent copy of the operating
system, including separate root logins. Therefore, if one of the vPars
were compromised in a security attack, it would not
be possible for them to gain access to processes running inside another
vPar except through the network, as with any other separate system.
Performance Characteristics
We
describe this technology as peak performance virtualization because the
physical resources of the system are assigned to partitions and once
they are assigned, the operating system in the partition accesses those
resources directly. The tradeoff here is flexibility. For example, each
I/O card slot can only be assigned to a single vPar. However, because
the OS interfaces directly with the card, no translation layer is
required. If I/O performance is critical for an application in your
environment, you will want to ensure that the solution you are using
supports this direct I/O capability.
