Resource Management Guide : Understanding and Managing Resource Pools : Creating Resource Pools : Understanding Expandable Reservations

Understanding Expandable Reservations
When you power on a virtual machine or create a resource pool, the system checks whether the CPU and memory reservation is available for that action.
If Expandable Reservation is not selected, the system considers only the resources available in the selected resource pool.
If Expandable Reservation is selected (the default), the system considers both the direct parent resource pool and any ancestor resource pool when performing admission control. Ancestors include direct parents, parents of the parents, and so on. For each ancestor, resources can be used only if the ancestor pool is set to expandable for each ancestor and no Limit is set that would stop it from becoming larger by borrowing resources. Leaving this option selected offers more flexibility, but, at the same time provides less protection. A child resource pool owner might reserve more resources than you anticipate.
 
Note
 
Expandable Reservations Example
Assume an administrator manages pool P, and defines two child resource pools, S1 and S2, for two different users (or groups).
The administrator knows that users will want to power on virtual machines with reservations, but does not know how much each user will need to reserve. Making the reservations for S1 and S2 expandable allows the administrator to more flexibly share and inherit the common reservation for pool P.
Without expandable reservations, the administrator needs to explicitly allocate S1 and S2 a specific amount. Such specific allocations can be quite inflexible, especially in resource pool hierarchies, and can complicate tree operations in the resource pool hierarchy.
The downside of expandable reservations is a loss of strict isolation; that is, S1 can start using all of P's reservation, so that no memory or CPU is directly available to S2.