Configuring and Migrating Memory on vPars

Memory Resource Assignment

In a vPars system, by default, a partition does not get any memory when it is created. Hence, the

memory required for a partition must be explicitly added. There are two parts to the memory

assignment: the amount and the actual address ranges that form this amount. This chapter describes

how to assign memory while creating the database, how the vPars monitor divides the memory that it

finds among partitions during monitor boot, how memory ranges get bound or unbound during

partition boot, shut down, online add and delete, and some of the side effects of the binding.

The first section describes the division of memory between partitions while creating and modifying a

non-live

database. The second section describes the memory operations on a live database including

partition boot, online add, and online delete.

Memory Allocation – Non-live Database

The vPars software does not validate the resources that are assigned to each partition against the

resources that are present in the system where the non-live database is being modified. With respect

to memory, the system administrator must take inventory of the physical memory of each type (ILM

and CLM in each cell) on the target system and reduce from that the memory that will be taken by

firmware and vPars monitor prior to creating the database and assigning memory to the partition. The

memory assigned to each partition is known as requested memory and vPars software allows the

modification without checking whether it can allocate the requested memory when this database is

actually used later to partition the target system.

When the vPars monitor is booted, it takes inventory of the memory of each type available for use.

The monitor then allocates each partition’s request based on the order in which the partitions are

found in the database. The base memory request of each partition in the database is satisfied before

any floating memory request. If, during allocation, the amount of memory available is less than the

amount of memory requested whatever available is allocated to the partition. Hence, if total ILM or

CLM memory requested in the database is more than the available ILM or CLM in the system, one or

more partitions at the end gets less memory or zero memory.

In the example setup in previous chapter, the system contains: 4 GB ILM, 2 GB of CLM from cell 0

and 2 GB of CLM from cell 1. Assuming the system administrator creates vpar1 before vpar2 and

then assigns 1 GB of ILM as base and 1GB of ILM as floating to vpar1 and vpar2. After the monitor

boot, the available ILM is 3712 MB because 384 MB out of the 4 GB is used by the monitor and

firmware. The vPars monitor allocates base memory first. Hence, vpar1 and vpar2 each get 1 GB of

base memory. However, for floating memory, vpar1 will get 1 GB of floating memory whereas vpar2

will get 640 MB. Hence, vpar2 gets less floating memory than what it requested. To avoid such

oversubscription, the system administrator can do one of the following:

1. Do not assign all the memory in the system among partitions. Instead leave some amount of

memory free for use by vPars monitor and firmware (described in more detail later in Memory

Accounting Chapter) while assigning memory to partitions.

2. Create just one partition and assign the required memory to the partition. After that, boot the

monitor and the partition and take inventory of the actual available memory using vparstatus

–A and then create rest of the partitions assigning to them available memory.

A database is non-live or alternate database under following two conditions: (i) HP-UX is booted stand-alone (not under vPars monitor) and

vPars commands are used to create and modify the database. (ii) HP-UX is booted under vPars monitor, however, the database being created

or modified is the database that the vPars monitor is not currently using.