One of the questions I was often asked about resource pools (RP) is ‘Expandable reservation’. What is expandable reservation, and why should I care about it? Although it sounds intuitive, it can be easily misunderstood.
To put it simply, a resource pool with ‘expandable reservation’ can expand its reservation by asking more resources from its parent .
The need to expand reservation comes from the increase in reservation demand of its child objects (VMs or resource pools). If the parent resource pool is short of resources, then the parent expands it reservation asking resources from the grand parent.
Let us try to understand this with a simple example. Consider the following RP hierarchy. If RP-4 has to expand its reservation, it requests resources from its parent RP-3 and if RP-3 has to expand resources it eventually requests Root-RP.
Resource pool with fixed reservation
A resource pool with fixed reservation cannot expand its reservation and any operation that needs reservation would fail incase of resource shortage.
Taking the above example, all the RPs have expandable reservation set. Then I changed the reservation of RP-4 from “Expandable” to a fixed value of 300MB as shown below.
Now the “Resource settings” for the RP-4 are,
We can see that, although the reservation used by all the VMs is zero, the RP-level used reservation is shown as 215MB. This reservation is coming from the VMs’ overhead memory (as computed by ESXi).
At this point I add two more VMs to the resource pool and powered-on one of them. Now the RP-level used reservation changes as shown below.
When I power-on another VM in the RP, it fails with error as shown below.
This happened because in this case, there wasn’t enough memory available to accommodate the new VM (its overhead memory needs to be reserved). Then, I change the reservation type back to “Expandable” and the power-on succeeds.
As we can see from the above figure, although the configured reservation shows 300MB, the used reservation is 321MB, which is the result of expandable reservation.
This is just one example of how expandable reservation can be useful. If the VMs inside the RP have their own reservations, then those will also be accounted for in the used reservation of the RP.
Hence, it is always advisable to keep RP reservation as “Expandable” as it can accommodate any increase in reservation demand by asking for more resources from the parent resource pool.
In the next post, we will look at how these reservations for a resource pool are different from the reservations for a VM and when to use them.
HI Sai,
Thanks for the brief yet in-depth write-up.
In doing my own testing of Resource Pools, I noticed that you cannot uncheck the expandable reservation box and leave the reservation at 0, otherwise you will get an “…resources in the parent resource pool are insufficient…” error when attempting to power on VMs. You have to either manually assign a number for the reservation, or you have to leave the expandable reservation box checked.
I thought a reservation was an optional parameter that allows you to set a minimum guarantee of a specific resource on an object. The results of my testing would indicate that a reservation, whether a manually assigned reservation or expandable reservation, is a mandatory parameter that needs to be configured when creating a resource pool. Is this observation correct?
Thanks again,
Austin
Austin,
In a Resource Pool, to run a VM, certain amount of memory needs to be reserved, mainly for “overhead memory” of VMs. when you uncheck ‘expandable reservation’ and set reservation to ‘0’, then powerOn will fail because it cannot reserve resources equivalent to overhead memory of VM. when you set it to expandable, though the configured value is ‘0’, it will expand reservation asking more resources from parent pool.
your definition of reservation is correct for a VM where it is completely optional. But for a Resource Pool, it needs to reserve certain memory to powerOn a VM.