VMware vSphere Reservations Shares Limits and Resource Pools

VMware gives us several tools to manage Memory and CPU resources on a host or cluster. It can be confusing to understand how to manage them, so let's look at them systematically.

Reservations:

A reservation is an absolute guarantee of memory or CPU for a virtual machine or a resource pool. Reservation assignments are measured in specific Megabytes (MB) of memory or Gigahertz (Ghz) of CPU. When are Reservations relevant? When you must provide an absolute minimum guarantee of resources for a particular application to run (or run well).

Example:64 GB of RAM available on a host
VM1: 11 GB Reservation
VM2: 13 GB Reservation
Remaining: 40 GB for all other VMs

Carving out resources with Reservations

Remember that the reservation is separate from the RAM assignment of the VM. For Example, VM1 might have an assignment of 15 GB of Memory but is Reserved 11 GB. Therefore 4 GB may be allocated from VMware physical RAM or failover to swapfile capabilities. If VM2 has a 15GB assignment in addition to the 15 GB reservation then 100% of its memory is guaranteed to be allocated from physical RAM.

Memory Reservation

CPU Reservation

Shares:

A Share are a proportional weighted assignment of memory or CPU processing power. Shares are relative resource assignment measured by a number of shares of Memory or CPU. Think of it like shares of stock in a company. The more shares there are, the less yours are worth in voting power.
Administrators will assign top tier applications (e.g.: Database Server) more shares than lower tier applications (e.g.: FTP Server) When do shares become relevant? When you OVER-ALLOCATE resources and must balance requests for resources among several VMs.

There are 4 share settings-

• High = 2000 shares per vCPU and/or 20 shares per MB of configured memory
• Normal = 1000 shares per vCPU and/or 10 shares per MB of configured memory
• Low = 500 shares per vCPU and/or 5 shares per MB of configured memory
• Custom = configure the numeric allocation of shares for CPU or memory

CPU Share configuration

Memory Share Configuration

If there is no contention for available resources, Shares don't matter. For example, if there is a single shared core with 9Ghz available and each system needs 2Ghz - there's no issue. But when there is competition for resources Shares become very important. In that same single core 9Ghz host where both systems want 100% processor utilization there will have to be a division of processing labor.

If both VMs have the evely distributed default share assignment of 1000, the two systems will have 50%/50% access to the vCPU.

CPU allocation under contention will be equal between VM1 and VM2

However, if VM1 has a is normal (1000) allocation but VM2 and another has a custom allocation of 3000 shares then when under contention VM1 will have 1000/4000 (25%) access to the resources and the other VM has 3000/4000 (75%) access to the processor.

CPU allocation under contention is now tipped to give VM2 more CPU cycles

Limits:

Limits are a way to prevent a VM from using available memory or CPU. It should only be used in testing and development, since it is designed to cripple a VM's performance.

CPU Limit

Resource Pools:

Resource Pools allow you to create a shared container that defines the Reservations, Shares, and Limits that apply to the group of all VMs within it. This is NOT an inheritance setting, but a (as the name implies) pool of defined resource allocation for the benefit of all who are within it.

For example, if a regular reservation is like carving out an office on an unpartitioned floor of a building, a Resource Pool allocation lets you carve out an office that will be shared by more than one employee.

Example:
Example:64 GB of RAM available on a host
VM1: 11 GB Reservation
VM2: 13 GB Reservation
Resource Pool (parallel to top level VMs) : 20 GB Reservation
Remaining: 20 GB for all other VMs

Reservations with Resource Pool

How about if we use Resource pools in conjunction with Shares? The proportion of resources are allocated among the top tier items, whether they are VMs or Resource Pools. Then within a resource pool you provide the means of allocating the portions within.

This would look something like this:

Shares with Resource Pools

Example:
Two resource Pools are built, each with two VMs. Share allocations are as follows:

• RP1: 1000
• VM1: 1000
• VM2: 3000
• RP2: 3000
• VM3: 1000
• VM4: 3000

So what percentage of CPU resources when the system is under stress would be allocated to the VMs?

• RP1: 1000 (25% of overall CPU)
• VM1: 1000 (25% of the 25%)
• VM2: 3000 (75% of the 25%)
• RP2: 3000 (75% of overall CPU)
• VM3: 1000 (50% of the 75%)
• VM4: 1000 (50% of the 75%)

That means that if 10Ghz were available, then

• RP1: 2.5 Ghz (25% of CPU)
• VM1: .625 Ghz (25% of the 25%)
• VM2: 1.875 Ghz (75% of the 25%)
• RP2: 7.5 Ghz (75% of overall CPU)
• VM3: 3.75 Ghz (50% of the 75%)
• VM4: 3.75 Ghz (50% of the 75%)

Notice that VM4 which has a share allocation of only 1000 ends up with more CPU cycles than VM2 which has a share allocation of 3000! Why? Because VM4 is in a prioritized resource pool.

Just to throw another twist for you, you can nest Resource Pools - though practically you shouldn't more than a few layers deep. The principle stays the same - Your reservations will create carved out absolute allocations, your shares will load balance contended-for resources within that container relative to others, and limits will define the maximum amount of resources available.

Let me know if you have any questions. Hope this helps!