This example shows how a resource pool with expandable reservations works.

Assume the following scenario (shown in Admission Control with Expandable Resource Pools: Successful Power-On).

Parent pool RP-MOM has a reservation of 6GHz and one running virtual machine VM-M1 that reserves 1GHz.

You create a child resource pool RP-KID with a reservation of 2GHz and with Expandable Reservation selected.

You add two virtual machines, VM-K1 and VM-K2, with reservations of 2GHz each to the child resource pool and try to power them on.

VM-K1 can reserve the resources directly from RP-KID (which has 2GHz).

No local resources are available for VM-K2, so it borrows resources from the parent resource pool, RP-MOM. RP-MOM has 6GHz minus 1GHz (reserved by the virtual machine) minus 2GHz (reserved by RP-KID), which leaves 3GHz unreserved. With 3GHz available, you can power on the 2GHz virtual machine.

Admission Control with Expandable Resource Pools: Successful Power-On
This is admission control with expandable resource pools and a successful virtual machine power-on.

Now, consider another scenario with VM-M1 and VM-M2 (shown in Admission Control with Expandable Resource Pools: Power-On Prevented):

Power on two virtual machines in RP-MOM with a total reservation of 3GHz.

You can still power on VM-K1 in RP-KID because 2GHz are available locally.

When you try to power on VM-K2, RP-KID has no unreserved CPU capacity so it checks its parent. RP-MOM has only 1GHz of unreserved capacity available (5GHz of RP-MOM are already in use—3GHz reserved by the local virtual machines and 2GHz reserved by RP-KID). As a result, you cannot power on VM-K2, which requires a 2GHz reservation.

Admission Control with Expandable Resource Pools: Power-On Prevented
This is admission control with expandable resource pools with virtual machine power-on prevented.