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

Don’t put in the same bag Xeon and POWER virtual CPUs

Just a reminder: this blog is a mirror of the "main" site https://www-304.ibm.com/connections/blogs/performance (http://ibm.biz/demystperf)

In the pervasive virtual world the standard unit of performance capacity happens to be the virtual CPU (vCPU). “This virtual machine (VM) has 6 vCPUs”, “you will have to provide 8 vCPUs for that VM”, and the like are common sentences. It could be a reasonable metric of performance if the underlying physical CPUs and the hypervisor layer were all the same. But this is seldom the case: Intel Xeon processors combined with VMware ESX virtualization, and IBM POWER processors combined with POWERVM virtualization are very different beasts.

If you are in need to size or convert capacity between these dissimilar systems, or in need to have a solid comparison base, or would like to unmask tricks and pitfalls that plague the virtual world sizing, continue reading.

IBM POWERVM

The POWERVM term for vCPU is Virtual Processor (VP). The VM has, or sees, VPs. And these VPs are scheduled, in a time-shared manner, on POWER cores. Yes, read it again: one VP is scheduled on one core. I remark this because in the ESX / Intel world this is different, as you will see later.

Given this VP-to-core mapping, the VP capacity ranges between two values:

• In the best case the capacity of one VP is the capacity that one core can deliver, that is 1 VP is 1 core           
• In the worst case 1 VP is (1/10)th of core.

The actual VP capacity depends on the following factors (revisit  “Why is the Virtual Capacity so Important?” and “The Playground of the Virtual Capacity”  in this blog for a detailed explanation):

• configuration parameters of the VM the VP belongs to (entitlement, capped/uncapped attribute, uncapped weight)
• configuration parameters of all the other VMs sharing the same physical machine (PM)
• actual usage of capacity from all the other VMs sharing the same physical machine

Given this highly variable value, contrary to what one unit of measure must be, how have VPs been promoted to be a “standard” measure of capacity? Amazing, don’t you think so?

VMWARE ESX

The VM has, or sees, vCPUs. And those vCPUs are scheduled on Intel processor threads, in a time shared manner. The mapping is vCPU-to-thread, and is different than the POWER / POWERVM case (VP-to-core).

Given this vCPU-to-thread mapping, the vCPU capacity ranges between two values:

• In the best case the capacity of one vCPU is the capacity that one thread can deliver, that is 1 vCPU is 1 thread           
• In the worst case one vCPU is very small (I’m not aware of a low limit)

The actual vCPU capacity depends on the same factors described in the POWERVM case,

• configuration parameters of the VM the VP belongs to
• configuration parameters of all the other VMs sharing the same PM
• actual usage of capacity from all the other VMs sharing the same PM.

Benchmarking vCPUs

The reputation of the vCPU as a stable capacity unit of measure has been destroyed. A vCPU capacity can range from a full core (or to a full thread) to a small fraction, and even depends on alien factors (from other VMs)!  

Is there a way to put some sense in this nihilism?

Yes, it is. By taking a practical approach: use the best case values. You know that the actual performance will always be equal or worse than that, but we have to live with this.

To evaluate the best case let’s consider the two systems we analyzed in SAPS Olympics: single thread performance post in this blog.

Dell PowerEdge R730 2s/36c/72t Intel Xeon  E5-2699 v3 @2.30 GHz	Physical System	IBM POWER S824 2s/24c/192t POWER8 @3.52GHz
36	Cores	24
72	Threads	192

The best performance VM setup running on these systems is a single VM will all the processors assigned, that is:

• IBM POWER S824 2s/24c/192t POWER8 @3.52GHz with 24 VPs  (= 1 VP/core x 24 cores).
• Dell PowerEdge R730 2s/36c/72t Intel Xeon  E5-2699 v3 @2.30 GHz with 72 vCPUs (= 1 vCPU/thread x 2 thread/core x 36 cores).

And the final results would be:, without taking into the reduction of capacity due to virtualization:

Dell PowerEdge R730 2s/36c/72t Intel Xeon  E5-2699 v3 @2.30 GHz	Physical System	IBM POWER S824 2s/24c/192t POWER8 @3.52GHz
36	Cores	24
72	Threads	192
1	VM	1
72	vCPU / VP	24
90120	SAPS	115870
1250	SAPS/vCPU	4828

The dramatic difference, 4282 SAPS/VP vs 1250 SAPS/vCPU, would be even greater taking into account virtualization effects, as is widely known that POWERVM is more efficient than ESX. We may consider a 3-5% reduction for POWERVM and a 10-15% for ESX.

If the Intel Xeon Hyperthreading is switched off (HT=0ff), and this seldom happens in a virtualized environment, the capacity numbers would improve for Intel vCPUs to 2019 SAPS per vCPU  ( = 2019 SAPS/core x 1 core/thread x 1 thread/vCPU ), again without taking into account virtualization overheads.

Summarizing

Which capacity should be assigned to vCPUs? I would take the above estimated values, representing best cases in benchmark conditions, reduced between 3-5% for POWERVM and 10-15% for ESX. This results in this approximate and simple relationship:

1 POWER8 VP ≈ 4 Xeon Haswell-EP vCPU (HT=On)

Demystifying Virtual Capacity, 2nd Part and Tool

Hello:
Here are a new document and tool about virtual capacity: "Demystifying Virtual Capacity, Part II".

Abstract: The previous work, “Demystifying Virtual Capacity, Part I” is extended here to more that 2 virtual machines (VM). For solving the virtual capacity it has been created a companion spreadsheet helper: “The Virtual Capacity Demystifyier”. This tool is presented here, and its usage is illustrated with several simple use cases.

Section I: The VM Capacity Space. In this part the guidelines for solving the generic N virtual machines capacity problem are exposed.

Section II: The Dashboard. The user interface of the spreadsheet helper is presented. The inputs and the outputs are conveniently explained.

Section III: Scenarios. This is time to play with the tool. Several simple scenarios are presented, but the main purpose of this section is to show how to use the tool by example.

I hope you like it! Please, send me feedback as I would like to improve the tool in the future, as time permits...
Jorge L. Navarro

Demystifying Virtual Capacity, Part I

This is another contribution. Here is the link  http://ibm.biz/demvirtcap01

Abstract: When we enter in the realm of virtualization, performance related concepts and terms must be revisited: we move from the fixed capacity of physical machines, to the variable capacity of virtual machines. Which are the factors this virtual capacity depends on? How does this virtual capacity depend on those factors?

Currently I'm working in the Part II. I hope it will be ready soon, very soon.

I hope you like it and, please, give me feedback!

Jorge L. Navarro

The 65% Rule Revisited

Another document I authored:  http://ibm.biz/65-rule.

Abstract: This article deals with the 65% load limit warning that everyone in the sizing business is (or should be) aware with: don't go beyond 65% of the service center capacity! But in the virtual world a service center capacity is no longer a fixed value, so what happens then? How should this 65% rule be reinterpreted?

Hope you like it!

Jorge L. Navarro

The Sizer Advisor

Here are the links to two documents I authored on sizing, and a brief description:

• The Sizer Advisor, part I ( http://ibm.biz/sizadv01): This presentation expose ten elementary advices for sizers, the people dealing with sizing, sizing guidelines and related topics. Advices are generic, not particularly related to any specific sizing. Beginners should find it interesting, and experts may extract and reuse any slide for teaching their own trainees. 
• The Sizer Advisor, part II ( http://ibm.biz/sizadv02): This presentation is the second part of The Sizer Advisor series. It exposes ten additional elementary advices for sizers, the people dealing with sizing, sizing guidelines and related topics. Advices are generic, not particularly related to any specific sizing. 

I hope you like them!
Jorge L. Navarro

Welcome Message

During my long career I've always felt attracted to computer system performance themes: bandwidth, throughput, response time, sizing, bottlenecks, usage, capacity, saturation degree, and so on. Unfortunately, I've not always seen clear, understandable and knowledgeable explanations on these subjects. With the arrival of the virtualization paradigm even more complexity is introduced: terms that represented constant values, like the machine capacity, gets blurred. What can be said about a (virtual) machine capacity if it is no longer a fixed value and may change from this hour to the next? With this blog and related documents, I'd like to fulfill an educational purpose: illuminate -with a very dim light, I agree- any other's way into this huge field, by documenting and commenting on subjects I'd liked to know when I was a beginner. And still I am! Jorge L. Navarro