HP Virtual Server Environment: Tips for Application Developers

creation of a pset results in a pset with no processors. Therefore, it is necessary to add processors to
the pset before it can run processes.
Applications that are designed to be aware of the number of cores should take into consideration the
dynamic nature of the VSE environment. For example, an application that allocates one thread per
core, should consider the possibility that cores could be removed or more cores could be allocated.
The designer should consider whether the number of threads should be based on the current core
count, the maximum core count, or dynamically vary as the core count varies. Programmatic
interfaces to support all of these choices will be discussed below.
Sub-Core Partitions
This section covers the VSE partitioning solutions that support allocation of CPU resources in sub-core
granularity. Because these solutions allocate time slices of the physical cores to each partition, the
number of cores visible to each partition does not change when the CPU resource allocation increases
and decreases.
HP Integrity Virtual Machines
The HP Integrity Virtual Machines product provides a fully virtualized hardware platform to the
Operating System running in the virtual machine. This virtualized environment is so complete that
unmodified versions of the operating systems (HP-UX, Windows, and in the future Linux and
OpenVMS) can be installed in virtual machines. Note that HP Integrity Virtual Machines are unique
to the Integrity platform and are not supported on HP 9000 servers.
CPU “migration” in the case of Integrity VM is actually just an increase or decrease in the number of
physical core cycles that are made available to the virtual machine. Therefore, software running
inside the virtual machine does not see any change in the number of cores available. The user may
see momentary changes in the performance of the software based on how many cycles are available
and used by its virtual CPUs, and this is similar to how the software behaves when running on a
system with other application instances running within the same OS image.
Resource Partitions based on Fair Share Scheduler
The Fair Share Scheduler (FSS) controls the allocation of CPU resources between applications. It
allocates slices of CPU time, according to entitlements set by the system administrator. These
entitlements are referred to as “shares”, with typically 100 shares allocated per core. Applications or
workloads can be assigned as few as one share, or as much as 12800 shares (100 shares per core,
on a 128 core system). The Fair Share Scheduler ensures that each application or workload gets its
“Fair Share” of the available CPU resources.
While low level commands and interfaces are available, HP recommends using PRM (Process
Resource Manager) to manage Fair Share groups. See prm(1) for details.
Applications running in a Fair Share group will see all the cores that are available to the default pset.
Note that the number of cores in the default pset, and the number of shares available to an
application, are independent. Both can vary, independently. Cores can be added to or removed
from a running OS, and share entitlements can be changed dynamically by the system administrator
or the workload manager. Again, programmatic interfaces to query the number of cores in these
partition types will be discussed below.
Generally speaking, applications will not be affected by changes in the “real” amount of physical
cores allocated to virtual machines or share-based Resource Partitions. The exception would be an
application with requirements for real-time access to CPU resources.