[FASherman]

This happens to me all the time. I have a client who orders a p550, for example, with 32GB of RAM. They define LPARS and define all 32GB of RAM within those LPARs.

When they start powering up LPARs, they don't have enough memory to start up all of the defined partitions. What happened?

They forget that LPARs, dynamic or otherwise, are virtual machines. It stands to reason that there is a physical machine hosting these virtual machines, the hypervisor, and that the physical machine has memory requirements too.

In the case of a single small partition, the first 256 MB of memory will be allocated to the hypervisor, 256 MB is allocated to translation control entries (TCEs) and to hypervisor per partition page tables, and 256 MB for the first page table for the first partition. TCE memory is used to translate the I/O addresses to system memory addresses. Additional small page tables for additional small partitions will fit in the page table block. Therefore, the memory allocated independently of AIX to create a single 256 MB partition is 768 MB (0.75 GB).

So, how do you account for memory overhead? Here is how to calculate the range:

Minimum memory consumed can be calculated by dividing the total RAM (in GB) by 16, round up to whole integer values ( ie. 4/16 = .25, rounded up to 1). Multiply that value by .25, that add .5 to obtain the final minimum memory overhead.

For a 16GB server, the result is: (16/16)*.25 +.5 = .75GB of overhead minimum.

To obtain the maximum overhead, divide the total RAM by 32, roundin up. Multiply that value by .25 and add the minimum overhead to it.

Lets use a 32GB server as an example to determine the range of memory overhead:

Minimum = (32/16)*.25 +.5 = 1GB RAM overhead
Maximum = (32/32)*.25 +1 = 1.25GB RAM overhead.

If you remember to account for hypervisor memory overhead before configuring your LPARs, you'll save yourself a lot of headache later.

[DMWells]

Fred,

This exact situation happened to us when we purchased our first p690 a few years ago. The Technical Architects and Management ignored advice from IBM and their own Technicians (ie me), and built the machine to a budget rather than a specification, allowing only for the memory required by the clients.

Good old Hypervisor hey, the result was that one of the clients didn't have enough memory to run their applications, so after paying all that money for a new server they had to wait until our Department paid to upgrade the memory needed to run the frame itself plus that of the LPAR's.

Another point to remember is that the size of the Hypervisor is calculated and configured, at the time the LPAR is booted, based on the size of the maximum memory figure set in the profile, not the desired figure. So if you use the DLPAR capability of the server to share memory around, you may set the maximum value higher, but if you cross a memory boundry the Hypervisor will grab some more memory for itself, just in case you decide to add more memory to the LPAR later on.

It can be a trap if you don't know about it because you can spend all your time investigating the amount of memory your LPAR's have, rather than the maximum memory they may be given. So it's good to sit down and think about the maximum value and don't just set it to a big size because you might add more memory later.