A four-node AHV cluster managed by Prism Central has 64 vCPUs per node. Existing VMs reserve 240 vCPUs total. A new VM is requested with a 32 vCPU CPU reservation. Memory, storage, and network capacity are ample. Which placement outcome should you predict?
Select an answer to reveal the explanation.
Short Explanation
Think of CPU reservations like parking spaces: once they’re assigned, they’re not free traffic. If your existing reservations plus the new VM’s ask exceed what’s available, placement fails even when memory, storage, and network look healthy. That’s the trap — the problem isn’t performance, it’s capacity accounting.
Full Explanation
CPU reservations are capacity claims, not performance hints. When a VM is created with a reservation, the placement engine must ensure the cluster can satisfy that guaranteed CPU allocation before admitting the workload. In a cluster with limited vCPU capacity, the sum of existing reservations plus a new reservation can exceed available capacity, causing placement failure even if unreserved resources appear sufficient. A failed placement driven by CPU reservation exhaustion is a resource accounting condition, not a workload performance condition. A claim that CPU reservations allow overcommitment is wrong because a reservation is intended to guarantee capacity; overcommitment applies to unreserved or limit-based allocations, not to guaranteed reservations. A claim that memory reservations conflict with CPU reservations is wrong because these are separate resource dimensions, and a memory reservation does not consume CPU capacity. A claim that Prism Central converts a CPU reservation into a CPU limit is wrong because conversion changes the guarantee semantics and is not an automatic placement fallback. Exam caveat: the question tests placement behavior, not how to tune CPU limits or memory ballooning. Operational check: compare total requested CPU reservations against cluster reserved CPU capacity and reduce, move, or reconfigure reservations before requesting the new VM.