Resource Pools not functioning as intended

[Chr1s]

Hi,

I have a question regarding an issue I'm having with the resource pools in our ESX cluster. I've created a test resource pool setup to trial how we want things configured for production.

The setup I've put together to mimic production is:

One master resource pool set to a CPU reservation and limit 2000MHz and the same for RAM (2000MB res and limit). I've done this to mimic a physical blade with fixed resources available.

Two child resource pools underneath this. Both pools use only shares (rather than reservations or limits), "Expandable" and "Unlimited" are checked for both CPU and RAM with no Reservations set. The first child pool has shares of "2500" for both CPU and RAM, and the second has shares of "7500" for both CPU and RAM.

Now, my thinking here is that this provides a 25% and 75% split of resources. So, if there was 1 VM under each resource pool, and both were fighting for CPU, I would expect the VM in the 75% resource pool to get 75% of the CPU available (i.e. 1500HMz), and the VM in the 25% resource pool to get 25% of the CPU (i.e. 500MHz).

I've set up a VM in each resource pool (both from the same template) and run some tests. When I boot up the VM's, my theory looks correct, as the VM in the 25% resource group takes much longer to boot than the VM in the 75% resource group (I set both VM's booting at the same time). However, when I run some CPU stress tools within the VM (i.e. run the CPU to 100% in the VM), both VM's take an equal amount of CPU (i.e. 1000MHz each).

Can anyone shed any light on why this is and why the shares-based resource pools don't seam to be managing this properly? (have I configured them wrong?). I've attached images of the setup.

Many Thanks in advance,

Chris.

[Chr1s]

... and here's an image of the Resource usage.

Thanks,

Chris.

[TiJa]

Chr1s,

What is the clockspeed of the physical CPU (and hence: CPU cores) that you are using?

If the clockspeed is lower than 1.5 GHz (i.e. 75% of the 2 GHz reservation), then you don't have a way of physically providing a single 1.5 GHz CPU block for VM (and it is not possible to schedule a single vCPU over 2 physical CPU cores to accumulate physical CPU MHz's).

Bye!

Message was edited by: TiJa -removed a remark regarding the 2 GHz resource pool

[epping]

where is your contention ??

how many vprocs are in your test vms, how many cores are in your physical server ?

if you have more that three cores and your vms only have 1 vproc, both can run at 100% on the physical core with out contention, the shares do not come into play.

i am interested in why you want to use resource groups ?

epping ?:|

[Chr1s]

Hi TiJa,

Thanks for the reply 🐵

Regarding your first comment - that part works. The master resource pool is fixed at 2GHz, and the two VM's running in the two child resource pools do not shoot over that 2GHz limt between them (as seen in the screenshots I attached), so that limit is working correctly - it's the provisioning of resource below that which is not working.

The clock speed of the physical CPU is 3GHz, so this should not be an issue?

Thanks,

Chris.

[TiJa]

<span class="jive-thread-reply-body-container">i am interested in why you want to use resource groups ?

We have received several similar requests from projects in our company. The requirement sheets for a product that needs to be implemented on a virtual machine typically lists a set of physical server specifications (number of processors/cores, memory, disk space, ...). To ensure full vendor support, some project leaders ask a "guarantee" that they will get a number of cores (or computing power) and memory on a virtual machine (yes, we have given them the entire "shared resources", "shares" and "it's virtual, don't worry' speech). In such a case, one would expect that resource groups with limitations & reservations can provide an answer to that question for the persistent.

In our experience, we found out that resource pools and some unnecessary overhead & that indeed the resources are not entirely guaranteed (despite reservations; problematic in particular for vSMP machines due to known scheduling troubles with those machines). But still I am interested to know why this doesn't work as intended as the VI3.5 course uses this same example to illustrate how resource pools work .

[Chr1s]

Hi epping,

I've set this up on atest system, so there are no VM's running on here other than my two test VM's. Each VM have 1 vCPU and the physical server has 2 Quad Core CPUs.

So, if I'm understanding you correctly, the shares only come into play when a VM is contending for the same physical CPU core?

We are using resource groups for a number of reasons. We can split our pool of resources (currently 16 blades) into a "Dev and Test" area and a "Production" area, with the dev/test having lower shares than production. This means we can take advantage of the pool of resources without risking impacting production servers. Also, by using resource pools with shares, our environment can expand dynamically without us having to manually adjust limits/ reservations etc each time we add more CPU/ RAM to the cluster. I understand that some people don't do this and use hard limits/ reservations on their VM's to provide a guaranteed service that manages the performance expectations for the user (i.e. it will only ever use X amount of resource), but that doesn't currently fit our environment (not to say we won't use it in the future).

Thanks,

Chris.