Implementing a Virtual Server Environment: Getting Started

use of partitioning solutions. If you chose cell-based system, the next step is to consider adding iCAP
or TiCAP resources.
Utility Pricing
It’s easy to see that you should use iCAP resources if you are planning to run on a cell-based system.
Perhaps you even chose a cell-based system specifically because of the iCAP capabilities. iCAP is a
very cost- effective way to have spare capacity available for growth, whether expected or
unexpected. Most of the cost for this additional capacity is deferred until you need it, and it can be
activated dynamically with no disruption to your users. It’s a very low-risk and simple option.
TiCAP resources are useful if the increases in your workload demand are spiky or cyclical (seasonal,
monthly, or weekly). Again, this is not risky to implement, and it will add only a small amount of
complexity in order to automate TiCAP resource management with WLM or gWLM so you can better
manage its usefulness and cost.
Data from the worksheet in Table 2 can help you determine how many iCAP and TiCAP resources are
appropriate for each independent workload. The number of cores required for peak processing is the
number of TiCAP cores that you need, and the number of cores for expected growth is the number of
iCAP cores that you need. Again, at this point in the process, this data is still independent of resource
sharing. That topic is discussed in the next section.
Organizing partitions and resource sharing
Now that you understand the resource requirements for each application or workload, and now that
you have chosen which type of partitioning technology is the best fit, you must determine the best way
to organize and combine the partitions. This can get a little complicated because of the numerous
variables that factor into this decision. The first consideration is based on the sizing rules and limits.
Table 4 describes the rules and limits for each type of partition.
Table 4. Partition sizing rules and limits
Type of partition Sizing rules
nPars Must be one or more cells.
vPars One or more vPars can be in the same nPar.
Maximum number of cells per nPar is 8 (when vPars are used).
Maximum number of vPars per nPar is 8.
Maximum number of vPars in one nPar is also a factor of CPU, memory, and
I/O needed for each instance of HP-UX (cannot exceed resources of the nPar).
Integrity VMs and vPars cannot be in the same nPar.
Integrity VM Each virtual machine can have a maximum of 4 virtual CPUs.
Maximum number of virtual machines per physical processor is 20 (due to 5%
entitlement granularity).
One VM Host per nPar or server (non-cell based) is allowed.
Maximum number of virtual machines per VM Host is a primarily a factor of the
CPU, memory, and I/O requirements of each guest OS (or 254, whichever
comes first).
Integrity VMs and vPars cannot be in the same nPar.
17