How much capacity does a virtual cpu guarantee?

The rapid answer to the question how much capacity does a virtual cpu guarantee? is as much as one core can deliver (PowerVM VP), or as much as one thread can deliver (ESX vCPU). This is the best case, and so has been In the two previous entries ( “Don’t put in the same bag Xeon and POWER virtual CPUs”, “More on ESX vCPU versus PowerVM VP” ). But the best case is not necessarily the most common case.

Two typical non-best cases in the real world:

• For a good technical reason, trying to leverage the “sharing” capability that virtualization technologies enable,
• For a bad economic reason, reselling the same underlying physical capacity to more than one customer.

Independently of the true reason, you should be aware of a parameter, assigned to a VM, that helps a lot in specifying how much capacity does your particular VP (vCPU) guarantee. It’s called Entitlement in PowerVM, and Reservation in ESX. These parameters have a very interesting property: they cannot be overcommitted, that is, you cannot distribute among the VMs more Entitled (Reserved) capacity than is available in the physical machine. On the contrary, you can create and distribute more VPs (vCPUs) than existing cores (threads). If you simply divide the VM Entitlement (Reservation) by the number of VP (vCPU) in the VM you will have how much a virtual cpu guarantees.

Let us illustrate this with a very simple scenario, a reasonable setup for two VMs, the Red VM and the Blue VM, with the same importance. This situation may arise, i.e.,  when two productive environments share the same PM.

Physical Machine	IBM POWER S824 2s/24c/192t POWER8 @3.52GHz
Cores	24
SAPS	115870
SAPS/core	4828

Red VM		Blue VM
12	Entitlement (cores)	12
24	Virtual Processors	24
Uncapped	Cap/Uncap	Uncapped

The reason for 24 VP per VM, instead of 12 VP, is for the VM to be able to reach the 100% capacity of the PM.

In the best case (for the Red VM) the Blue VM remains idle, and under such a circumstance the 24 Red VPs can use the 24 cores, giving the equivalence 1 VP = 1 core = 4280 SAPS. To simplify we are not taking into account capacity reductions due to virtualization.

In the worst case (for the Red VM), the Blue VM is fully loaded and then the 24 Red VPs can use 12 cores at most, the Entitlement, giving the equivalence 1 VP = 0.5 core = 2140 SAPS.

So the actual Red VP capacity will be somewhere in the interval [2140, 4280] SAPS, depending on the Blue VM usage. Never will be less than 2140 SAPS, the guaranteed or worst case. Never will be more than 4280 SAPS, the underlying core capacity.

By the way, this is a good illustration of the good technical reason for overcommitting VP (vCPU) mentioned above. But may also be an example of the bad economic reason: just imagine that the owner of the physical machine sells the 24 VPs to the red customer, and 24 VPs to the blue customer, promising 1 VP = 4280 SAPS to everyone!

Summarizing

If you only know the number of VP (vCPU) that your VM has been assigned, you don’t have enough information to establish its precise capacity point. At least you should be informed of its Entitlement (Reservation) to derive the guaranteed capacity.

	PowerVM	ESX
Best Case	1 VP = 1 core	1 vCPU = 1 thread
Guaranteed / Worst Case	1 VP = Entitlement/NumberofVP	1 vCPU = Reservation/NumberofvCPU

Mirror: https://www-304.ibm.com/connections/blogs/performance/entry/how_much_capacity_does_a_virtual_cpu_guarantee?lang=en_us