A new application will deploy several AHV VMs with high vCPU and memory reservations. Before placing them, you review cluster capacity. Which planning step prevents placement failures?
Select an answer to reveal the explanation.
Short Explanation
Think of reservations like seats you have already sold: the cluster may look empty, but those vCPUs and RAM are not free for placement. When you forecast runway, you count reserved CPU and memory first, then see what is actually left for the new app. If you only watch storage, you can still fail placement.
Full Explanation
Reserved vCPU and memory allocations reduce the schedulable resources available for new VMs. For capacity planning, runway forecasting must evaluate CPU and memory reservations alongside raw host capacity, because placement succeeds only when a host can satisfy the reservation at admission time. In capacity views, reserved capacity should be subtracted from total capacity to determine realistic headroom before deploying a workload with large resource guarantees. Increasing storage containers does not address CPU or memory admission constraints; storage runway can look healthy while compute reservations block placement. Raising VM reservations further consumes more schedulable capacity and can make placement harder, not easier, because each reservation must be guaranteed by a host. Compression and deduplication reduce stored data footprint and may improve storage efficiency, but they do not create vCPU cycles or RAM for a reservation. Exam caveat: capacity questions may separate storage runway from compute runway; reserved CPU and memory are compute admission constraints, not storage efficiency opportunities. Operational check: compare total vCPU and memory per node with currently reserved allocations, then confirm that the target node still meets the new VM reservation after subtracting existing reservations.