1V0-21.20PSE · Question #106
A system administrator needs to configure a virtual machine to guarantee that it always gets the appropriate resource even if the host os overloaded and overcommitted. Which setting on the virtual…
The correct answer is C. CPU and Memory Reservations. HA Admission Control is set on the cluster, not on a VM. https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.resmgmt.doc/GUID- 8B88D3D8-E9D9-4C05-A065- B3DE1FFFB401.html?hWord=N4IghgNiBcIE4FMDOC4DcwBcCWB7AdkiAL5A…
Question
A system administrator needs to configure a virtual machine to guarantee that it always gets the appropriate resource even if the host os overloaded and overcommitted. Which setting on the virtual machine does the administrator need to configure?
Options
- AvSphere High Availability Admission Control
- BCPU and Memory Shares to High
- CCPU and Memory Reservations
- DHigh Performance Power Policy
How the community answered
(64 responses)- A5% (3)
- B2% (1)
- C84% (54)
- D9% (6)
Explanation
HA Admission Control is set on the cluster, not on a VM. https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.resmgmt.doc/GUID- 8B88D3D8-E9D9-4C05-A065- B3DE1FFFB401.html?hWord=N4IghgNiBcIE4FMDOC4DcwBcCWB7AdkiAL5A https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.avail.doc/GUID- 53F6938C-96E5-4F67-9A6E-479F5A894571.html
Topics
Community Discussion
14C is the right call here. Reservations carve out a guaranteed floor of CPU and memory that the hypervisor cannot give away to other VMs, so even when the host is overcommitted, your VM is protected and always gets what it needs, unlike shares which are just a relative priority hint that only matter during contention.
The correct answer is C, CPU and Memory Reservations. A reservation carves out a guaranteed floor of physical resources that the hypervisor must always honor for that VM, regardless of contention on the host. Shares only influence priority during contention and do not guarantee anything when the host is overcommitted, and HA Admission Control protects cluster-level failover capacity rather than per-VM resource floors. The High Performance Power Policy affects CPU frequency scaling on the host and has nothing to do with resource guarantees for a specific workload.
Reservations are the only hard guarantee, full stop. Shares just set priority in a contest, and HA admission control is a cluster-level failover concept, not a per-VM resource floor, so C is the right pick and the only one that survives an overcommitted host by locking down MHz and MB that the VMkernel will never hand to another VM.
Grigory is right that reservations carve out a hard floor, but worth noting that admission control does enforce resource guarantees indirectly during failover by ensuring the cluster holds enough capacity to restart VMs, so calling it purely a scheduling concept undersells it a little.
Shares are the classic trap here, B looks appealing because "High" sounds like priority, but shares are a relative weighting that only kick in during contention and they guarantee absolutely nothing in terms of actual MHz or MB. A reservation is a hard lower bound the scheduler must honor before the VM is even allowed to power on, so if the host cannot satisfy the reservation, admission is denied outright. HA Admission Control in option A is a cluster-level policy that reserves cluster capacity for failover, not a per-VM resource floor, so do not confuse those two concepts. C is the only setting that gives you a contractual minimum regardless of what else is running on that host.
Solid breakdown, just worth adding that reservations also affect HA slot size calculations when you are using the slot-based admission control method, so on a dense cluster you can inadvertently inflate slot sizes and reduce your calculated failover capacity by handing out reservations too generously.
C is right, reservations guarantee minimum resources even under host overcommit.
Reservations do protect VMs from starvation under contention, but remember that a reservation set too high locks resources from the pool even when the VM is idle, so size them carefully against actual working-set demand rather than peak theoretical need.
Reservations are exactly the right call here. When you set a CPU or memory reservation on a VM, the host is contractually obligated to hold that capacity aside for that VM regardless of what every other VM on the host is demanding, which is precisely the guarantee you need when the host is overcommitted.
Solid point, though worth adding that over-reserving based on peak-of-peak guesses rather than actual working set data will starve the host of capacity it could otherwise recover through ballooning or TPS, so right-sizing the reservation number is just as important as the decision to set one.
Reservations are exactly the right tool here, they carve out a hard floor of CPU and memory that the hypervisor must honor regardless of contention or overcommitment on the host. Shares only affect relative priority during contention, so a VM set to High shares can still get starved, while a reservation cannot.
High Performance Power Policy stops CPU throttling, so resources stay guaranteed always.
Anjali, High Performance Power Policy just prevents the host from dropping CPU frequency, it does not reserve cycles for a specific VM, so another workload can still crowd it out. Option C, setting a CPU Reservation on the VM, is what actually guarantees the resource allocation through the vSphere scheduler.
Guys I keep seeing people pick C on this one but think about it, HA Admission Control is literally the feature that prevents vSphere from powering on VMs unless the host can guarantee resources, so A is what actually enforces that guarantee at the cluster level when things get overloaded. Shares just set priority in a queue, they do not guarantee anything when the host is truly slammed.