The administrator wants to power on VM-K2, which has a 2GHz CPU reservation. VM-M1, VM- M2, and VM-K1 are all powered on. VM-K2 is not powered on. The exhibit shows the parent and child resource reser

Even with RP-KID configured as expandable, the feature only works when the parent resource pool has unreserved headroom to lend. In this scenario the parent pool's resources are fully committed by the running VMs (VM-M1, VM-M2, and VM-K1), leaving no capacity to satisfy VM-K2's 2GHz CPU reservation, so the power-on admission control check fails.

Having 2GHz reserved for RP-KID does not mean 2GHz is currently free - VM-K1 is already powered on and consuming RP-KID's reserved allocation, leaving insufficient room for VM-K2.

This ignores the expandable reservation feature entirely; expandable reservation is specifically designed to let RP-KID exceed its own stated reservation by borrowing from the parent, so the reservation ceiling alone is not the blocking condition.

Resource pools provide no priority-based power-on override that bypasses admission control; a VM cannot power on if its required CPU reservation cannot be satisfied anywhere in the pool hierarchy.