Edit: Some links no longer work.
Entitled capacity and virtual processors frequently come into play when you’re working with shared processor pools, and multiple virtual machines are using that shared processor pool.
Originally posted July 12, 2012 by IBM Systems Magazine
Entitled capacity and virtual processors aren’t new to Power Systems. They frequently come into play when you’re working with shared processor pools, and multiple virtual machines (VMs) are using that shared processor pool.
However, many people struggle with these concepts, particularly individuals who are new to the Power platform due to a migration from some other flavor of UNIX.
Physical and Virtual CPUs
First, keep in mind you can never use more physical CPUs than virtual CPUs as defined in your LPAR. Even if you allocate one virtual processor to an LPAR and set it to be uncapped, you can’t run more than one physical processor because there would be no other virtual processors available.
This way, you can limit the LPARs in your shared processor pools even if your LPAR is uncapped and there are 16 processors available in a shared processor pool. You still won’t be able to use more than one physical CPU because you only allocated one virtual CPU.
A virtual processor can represent from 0.1 to 1 of a physical processor. If you have one virtual processor, the range it can physically consume will never be more than one. If you have three virtual processors, you can use from 0.3 to 3, but never more than three.
It makes sense, as you’re basically giving your VM the illusion that it’s dealing with a physical processor. If it boots up, and sees three virtual processors, even if it’s running on 0.3 physical processors, it won’t see more than three processors. If it’s running uncapped and wanted to use four physical processors, where would they run if there are only three virtual processors?
Complicating the Issue
Simultaneous multithreading (SMT) can confuse the issue more. With POWER7 you can have four SMT threads, so the one virtual processor you set up will appear as four logical processors in your VM. If you were to turn off SMT, you would only see one logical processor.
When you assign physical processor resources to your VM, you’re setting up your entitled capacity. No matter what the other VMs on your frame are doing, your VM is entitled to use that much physical processor. It might donate spare cycles it’s not using, but if the VM needs those cycles, it’s guaranteed to get them.
If your VM is uncapped, it can utilize excess cycles in the shared processor pool. By doing this, you might find your entitled consumption can exceed 100 percent. You might find your VM consistently runs at 300 percent of entitled capacity. Capping the VM will limit how much physical processor it can use, and you’ll never run at more than 100 percent of the entitled capacity. This is another way to limit a VM’s processor utilization—you can cap it as well as limit how many virtual processors it has.
No Easy Way Out
It would be easy to say, “Great, I’ll just leave all of my VMs uncapped and configure them to use all of the physical CPUs available by setting all virtual processors on all VMs to the same number of physical processors that I have in my shared processor pool, and let them fight it out.” Although this might be a way to get started, this method can have drawbacks.
Remember to pay attention to your workload. Consider the additional context switching you’ll see if your VM is uncapped, but its entitlement is too low. Keep in mind the number of virtual processors you’ve defined. If you’ve defined eight but only use two, you might end up with additional overhead on your system. Although the system does have processor folding—in which it won’t schedule work onto the unused virtual processors in order to have better memory cache hits—it’s best to avoid defining excess virtual processors in the first place.
Also remember that your virtual processors can impact your job stream. It might make sense to have four virtual CPUs and 1.6 processing units, this would give you 0.4 processing units on each virtual CPU. With a highly threaded workload, this might be optimal. However, if you have two virtual CPUs and the same 1.6 processing units, each virtual CPU gets 0.8 physical CPUs to utilize. Depending on the workload, this scenario might make more sense.
Monitor your workload and try to match up your real-life workload with the settings on the VM. If you entitled the VM to 0.5 physical CPU, but it’s consistently using two physical CPUs, try bumping up the entitlement so you know it won’t be starved for resources later. Right now, your pool might have enough capacity to allow the VM to use those two CPUs without issues, but if workload characteristics change, you could discover that jobs that used to run fine having issues because they’re starved for resources.
Another way to manage resources in an uncapped pool is by using the weights you assign to VMs through the hardware management console (HMC). This might not be as granular as you think. There won’t be much of a difference between one VM getting a 200 share, and another getting a 180 share. So use some meaningful numbers, make the higher-priority VMs 250 and the lower-priority machines 50, for example. You want the numbers to actually mean something when two VMs are competing for resources, and one is far more important.
Educate Yourself
For more on entitled capacity and virtual processors, I recommend the additional articles and IBM Redbooks papers listed in the Resources section of this article. Another way to learn more is by testing LPARs on a sandbox server and seeing what happens to your systems when you make dynamic changes to your physical and virtual processors on a running system. Reading about the topic is one thing, but to make sure you understand it, make changes and see if you get the results you expected.
An LPAR Review
https://robmcnelly.com/an-lpar-review/
Configuring Processor Resources for System p5 Shared-Processor Pool Micro-Partitions
http://www.ibmsystemsmag.com/aix/administrator/systemsmanagement/Configuring- Processor-Resources-for-System-p5-Shar/
IBM Redbooks
http://www.redbooks.ibm.com/redbooks/pdfs/sg247590.pdf
AIXpert Blog: AIX Virtual Processor Folding is Misunderstood
https://www.ibm.com/developerworks/mydeveloperworks/blogs/aixpert/entry/aix_virtual _processor_folding_in_misunderstood110?lang=en
POWER7 Virtualization Best Practice Guide
http://www.ibm.com/developerworks/wikis/download/attachments/53871915/P7_virtualization_bestpractice.doc?version=1