The old DRS algorithm, prior to the vCenter 6.7.0 release, did not reserve more resources than the current VM demand in the resource pool, even if the resource pool is configured with a higher reservation. If there is a spike in VM resource demand, DRS would react only after the next algorithm run. Before that periodic run, VMs might suffer from temporary performance issues even if the resource pool has configured enough reservation.
In vCenter 6.7.x, DRS uses a two-pass algorithm to allocate a resource pool’s reservation to its child VMs. In the first pass, the resource pool reservation is distributed and capped at the VM’s demand, subject to each VM’s fair share. In the second pass, excess reservation is distributed proportionally, capped at the VM’s configured size. Therefore, resource pool reservation is aggressively allocated to its children, giving more buffer to sudden VM demand spikes. For more information on vCenter 6.7.x DRS change, see:
DRS Enhancements in vSphere 6.7.
If a resource pool has a very high resource reservation value, there is a chance that it may reserve most host memory, ESXi kernel or agents may not be able to allocate new memory. This causes the above symptoms on the ESXi host. This is a known issue documented in: KB
52500. As mentioned previously, the 2-pass DRS algorithm adds more memory stress to ESXi if a resource pool uses a large memory reservation. Thus, the above symptoms could be more apparent after upgrading vCenter to a 6.7.x release.