DPC Virtual Tips

Working with a vSphere Resource Pool

On

By

admin

In

Reading Time: 7 minutes

Working with a vSphere Resource Pool is an article that briefly explains vSphere Resource Pools and provides some examples and case uses.

First and foremost, what is a vSphere Resource Pool?

vSphere Resource Pools allow you to delegate control over the resources of a host or a cluster. When we talk about resources, it means CPU and memory resources. It is a logical abstraction for managing resources. It can be hierarchically grouped and partitioned into available CPU and memory resources.

The topmost resource pool is called the root resource pool. In a standalone host, the total amount of CPU and memory is the root resource pool, and in a cluster environment, the sum of all CPU and memory resources is the root resource pool.

In the following picture, we can see important concepts about resource pools like root resource pools, sibling resource pools, child resource pools, and parent resource pools:

To see the root resource pool for a DRS cluster, for instance, we can select a cluster and see details under the “Capacity and Usage.” In this case, our root resource pool has the maximum values for:

  • CPU: 41.31 GHz
  • Memory: 383.84 GB

These resources can be “shared” into one or more vSphere Resource Pools, and some attributes control what workload will be prioritized during contention.

Some Reasons to Use Resource Pools

As we know, CPU and memory resources are limited in an environment and must be used carefully. So, with resource pools, it is possible to delegate control over all available resources, prioritizing them for important or specific workloads. Using resource pools can result in the following benefits:

  • Create different resource pools to handle different types of workloads (critical apps, dev apps, test apps, etc);
  • Create boundaries to apply permissions. For example, only a specific group can manage VMs inside the critical app resource pool.

When you use resource pools to handle or prioritize different workloads, this priority will only occur during congestions. In simple words, the resource pool “rules” will only occur during high or intensive resource usage (high CPU and memory usage) – just to prioritize the workload that needs to be prioritized.

Resource Pool Attributes

A resource pool has some attributes, as we can see below:

  • Shares:
    • Low: 2000 shares –> It means a lower priority for resource allocation
    • Normal: 4000 shares –> It means a normal priority for resource allocation
    • High: 8000 shares –> It means a higher priority for resource allocation
    • Custom: You can define a custom value for it
  • Reservation: In MHz and GHz for CPU, MB or GB for Memory
  • Reservation Type:
    • Expandable check box selected: VMs and sub-pools can borrow from this pool’s parent.
    • Expandable check box deselected: VMs and sub-pools can only borrow from this pool, even if its parent has free resources.
  • Limit:
    • In MHz and GHz for CPU, MB or GB for Memory.
    • Unlimited access, by default, up to the maximum amount of accessible resources.

As we can see in the following picture, we can adjust each attribute under the resource pool creation wizard:

Resource Pool Example of CPU Shares

As we learned in the previous topic, “shares” is an attribute we can configure into a vSphere Resource Pool. In this example, our root resource pool is our cluster composed of some ESXi hosts, and inside it, we have created some child resource pools, as shown in the following picture:

  • Cluster-A is our root resource pool
  • Engineering Pool is a child resource pool
  • Finance Pool is a child resource pool, too
  • Engineering and Finance are sibling resource pools

The finance resource pool has twice as many CPU shares as the engineering one. So, based on this, the finance resource pool is entitled to twice as many CPU resources as the engineering resource pool:

To explain the resource pool concept, let’s consider that the VMkernel schedules all the VMs onto the same physical CPU. These VMs are in direct competition with each other.

Since the finance pool has more CPU shares than the engineering pool, it will have more “time of CPU” than the engineering pool.

VMs inside each pool can have their CPU shares configured, as shown in the following picture:

  • Fin-Test VM has approximately 22% CPU priority inside the finance pool.
  • Fin-Prod VM has approximately 45% CPU priority inside the finance pool.
  • Eng-Test VM has approximately 11% CPU priority inside the engineering pool.
  • Eng-Prod VM has approximately 22% CPU priority inside the engineering pool.

These are just examples to explain how resource pools work in an environment.

Practical Example of How CPU Shares Works

First, five photon os VMs were configured with CPU scheduling affinity to “0”. It enforces all VMs running on the CPU 0 of the physical host:

All those five VMs are running in the same ESXi host. It is important to create the congestion condition:

Inside each photon os VM, we start a bash script to calculate the Pi value and show what time was needed to do it, as we can see in the following video:

As we can see in the video, all photon os VMs took approximately 20 seconds to run the bash script to calculate the Pi value.

Remember: All VMs have a CPU scheduling affinity to use the CPU 0 and run inside the same ESXi host.

After a few minutes, we can confirm that each VM has a similar time to calculate the Pi value, as we can watch in the following video:

Let’s create three resource pools:

  • RP-Critical VMs: High Shares –> Add PhotonOS-01
  • RP-Normal VMs: Normal Shares –> Add PhotonOS-02
  • RP-Non-critical VMs: Low Shares –> Add PhotonOS-03, 04, and 05

First, we must enable the vSphere DRS to create a resource pool. The short video below shows all the necessary steps to create each resource pool:

The bash script continues running on each photon-os VM. After creating the resource pools, we can check the execution time for each VM:

  • PhotonOS-01: It takes approximately 7 seconds to run the bash script (from 20s to 7s);
  • PhotonOS-02: It takes approximately 14 seconds to run the bash script (from 20s to 14s);
  • PhotonOS-03, 04, and 05: They take approximately 90 seconds to run the bash script (from the 20s to the 90s).

This means that the VM PhotonOS-01 has more priority in accessing CPU time than the other VMs because its resource pool has higher shares than the other resource pools:

The overall CPU usage of the ESXi host can be shown fine in the “Capacity and Usage” on the Summary dashboard. However, if we explore the performance CPU charts, we can see that the CPU 0 is under congestion (a 100% percentage of usage), as we can see in the short video below:

Let’s calculate what percent of CPU each resource pool has allocated:

“RP-CriticalVMs” and “RP-NormalVMs” resource pools have only one VM in each resource pool. So, based on this fact, all Shares (100%) available in its resource pool will be used for only one VM.

On the other hand, “RP-Non-criticalVMs” has three VMs. So, these three VMs will compete for the shares available in its resource pool. In our example, each VM will have approximately 33% percent of CPU:

About Expandable Reservations

Expandable reservation allows a child resource pool to borrow resources from a parent resource pool.

Let’s provide an example:

  • The root resource pool has 64.26 GHz of CPU (for this example, we only focus on CPU).
  • Each resource pool has its CPU reservation.
  • We can enable or not the expandable reservation for each resource pool. In our example, only one resource pool has this option enabled.
  • The “non-critical VMs” resource pool has three virtual machines. Each VM has its CPU resource pool configured. “PhotonOS-03” and “PhotonOS-04” have 2GHz of CPU reservation. However, “PhotonOS-05” could not reserve CPU because its resource pool did not have resources available for that:

I have tried to configure the CPU reservation to the “PhotonOS-05” but I received an error:

“The amount of CPU resource available in the parent pool is insufficient for the operation.”

To fix this error, we can enable the expandable reservation in this resource pool, as we can see in the following picture (I recommend powering off the VM before modifying it – I have just tried to modify it in a running VM, and it stuck the VM):

After that, we can edit the VM “PhotonOS-05” and add the CPU reservation:

Under the “Non-critialVMs” resource pool, we can see details of that:

Important: So, use the expandable reservation carefully. A single-child resource pool can use all its parent’s available resources, leaving nothing directly available for other child resource pools. You might want to deactivate the expandable reservation type when you configure a fixed amount of resources to a group.

To Wrapping This Up

This article could show you essential concepts related to the vSphere Resource Pool and its environmental importance. Shares are not the only way to prioritize a workload, but in my opinion, they are an effective way to achieve excellent results. You can explore the other resource pool attributes in a lab environment and later apply them in your production environment.