A latency-sensitive application VM on an AHV cluster occasionally slows when other VMs compete for CPU. The administrator must guarantee a minimum amount of CPU capacity for this VM without capping its maximum. Which resource control should be configured?
Select an answer to reveal the explanation.
Short Explanation
Think of a reservation like a seat you keep on the bus: if you set it, the scheduler can’t sell that CPU capacity to someone else. A limit only says you can’t stand over the line, and oversubscription just assumes most seats won’t be used. If you need guaranteed cycles, reserve them.
Full Explanation
A vCPU reservation tells the AHV scheduler to reserve a minimum amount of CPU capacity for a VM before scheduling other workloads, giving latency-sensitive applications predictable processor access. The reservation acts as a floor, not a ceiling: the VM can use more CPU if idle capacity exists, but it should not be starved below the reserved amount during contention. A CPU limit is wrong because it imposes a maximum and can throttle the VM even when capacity is available; it protects other workloads rather than guaranteeing capacity. Oversubscription is wrong because it relies on aggregate CPU demand being lower than physical capacity, allowing more vCPUs than cores and reducing predictability under load. Anti-affinity is wrong because it controls host placement by separating VMs, not CPU allocation; it may reduce noisy-neighbor effects but does not reserve cycles. Exam caveat: distinguish reservation, limit, and affinity—reservation guarantees minimum CPU, limit caps maximum CPU, and affinity controls placement. Operational check: compare the VM’s CPU reservation with measured steady-state CPU demand, then validate latency and contention metrics after applying the change.