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

Assume the following scenario, as shown in the figure.

  • 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.
    Figure 1. 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.

  • 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.
    Figure 2. Admission Control with Expandable Resource Pools: Power-On Prevented

    This is admission control with expandable resource pools with virtual machine power-on prevented.