You manage an AHV VM running a database that intermittently suffers guest ballooning during memory pressure, and you must guarantee a fixed amount of host memory for it without changing CPU or storage controls. Which resource control should you apply?

By default, AHV backs every VM's configured memory with physical host memory; it does not oversubscribe memory, so there is no separate memory reservation setting to configure. Memory overcommit is an opt-in, per-VM feature. When it is enabled, AHV may reclaim memory the guest isn't actively using, primarily through the balloon driver, so more VMs fit on a host. That reclamation is exactly what the database is experiencing during host memory pressure. Disabling memory overcommit on the database VM returns it to the default model, in which its entire configured memory is allocated on the host and is not ballooned away; the VM must be powered off to change the setting, and the host must have enough free memory to start it. A CPU reservation is not an AHV control and would not affect memory in any case. A memory limit, even if one existed, would cap the VM rather than protect it. A storage QoS throttle shapes disk I/O for VMs in a storage policy and has no effect on guest RAM. Exam caveat: ballooning on AHV is a symptom of memory overcommit being enabled, so the fix is the overcommit setting, not a vSphere-style reservation. Operational check: confirm the VM's memory overcommit status in Prism Central and watch the guest's balloon counters after the change.