1V0-21.20 · 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 mac
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 https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmwa
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
(16 responses)- A13% (2)
- B6% (1)
- C81% (13)
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
12The correct answer is C, CPU and Memory Reservations. Reservations are what actually guarantee a VM gets a minimum amount of CPU and memory no matter how busy the host gets, whereas Shares only affect priority when there is contention and do not promise any specific amount.
C is your answer. Reservations are a hard guarantee, they carve out an amount of CPU and memory that the host must always honor for that VM no matter how overcommitted things get, whereas Shares only give priority during contention and do not guarantee anything when resources run dry.
Shares (B) trip people up because they feel like a priority knob, but shares only redistribute contention, they do not establish a floor, so a host under extreme pressure can still starve a high-shares VM. Reservations (C) are the only mechanism that forces the scheduler to withhold capacity before powering on the VM, which is exactly the guarantee the question describes.
I almost picked B but Shares just adjust priority, Reservations actually lock resources guaranteed.
Right, and the part exams love to test is that Shares only matter during contention, so if there is no resource pressure every VM gets what it requests regardless of Share value, which is exactly the kind of qualifier word trap they put in the distractors.
The word "guarantee" is doing a lot of work here, because Shares (option B) only prioritize resources when there is contention, they do not lock in a minimum, so I keep coming back to Reservations as the one setting that actually promises a floor that the host must honor even under overcommitment. Can someone confirm whether a Reservation still holds if the host physically does not have enough physical RAM available, or does the guarantee only apply to the logical overcommit scenario the question describes?
Reservation holds through logical overcommit because vSphere admission control blocks VMs from powering on if their reservations cannot be satisfied by available physical capacity, so by the time a reservation is active the host has already been committed to honoring it, but if a host fails and the cluster cannot find capacity elsewhere your reservation means nothing without HA admission control set to cover it.
Shares (option B) trip a lot of people here because they feel authoritative, but shares are only relative weights that matter during contention, so a high share value still gives you zero guarantees the moment every other VM on the host is also fighting for resources. Reservations are the only mechanism that carves out a hard floor of CPU MHz and memory that the scheduler must honor regardless of host load, which makes C the clear answer.
Solid point, though worth noting reservations also carry a cost: overcommit headroom shrinks and if you set reservations cluster-wide without capacity planning, you can end up with VMs that fail to power on because the host can't satisfy the guaranteed floor.
Thought shares would do it, but reservations actually guarantee minimums regardless of contention.
Admission Control is literally what prevents overcommitment from stealing your VM's resources.
Bao, Admission Control does guard against overcommitment, but the question is asking specifically about what enforces resource limits on a running VM, and that is Resource Pools, which is C. Admission Control is the gatekeeper at power-on, not the ongoing enforcement mechanism.