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.