Detecting Memory Overcommit in the Guest OS is possible using the RamMap tool.

Here, at Bobcares, we assist our customers with several virtual machine queries on a daily basis.

Today, let us focus on how our Support Techs detect memory overcommit in the Guest OS.

Memory overcommit

When we administrate VMs that run on virtualization hosts, we often face situations where the size of available memory in the guest OS is much less than the operating system sees.

For example, a virtual machine has 8 GB of memory, the Task Manager shows that 1 GB is free though all running processes consume less than 3 GB. What about the rest 4 GB?

As a rule, this behavior is due to the use of the memory overcommit feature in the hypervisor.

Memory overcommit is a hypervisor feature that allows us to allocate more memory than is available on a physical host. However, it does not guarantee that all memory can allocate at a particular moment.

Memory overcommit allows allocating virtual machines more densely. It is due to dynamic memory distribution between VMs depending on the current host load.

One of the mechanisms for implementing memory overcommit in VMWare is Memory Ballooning. In Hyper-V, Dynamic Memory implements the same feature.

Memory overcommitment implements in VMWare ESXi by vmmemctl.sys driver, which can capture physical memory by creating a fake process in it if necessary.

Thus, the occupied amount of memory becomes unavailable to other applications in the guest OS. Hence, the hypervisor can distribute free memory between other VMs.

In Hyper-V Dynamic memory, we use a dmvsc.sys driver from the integration services. Hypervisor administrator manages the memory overcommitment settings.

[Looking for further details? We can help you!]

Detecting Memory Overcommit in the Guest OS

Let us consider how to detect a balloon driver in a guest Windows OS and what its size is. So, let us analyze this example.

VM running guest Windows Server 2012 R2 has 8 GB memory. The Task Manager shows the use of 93% of memory. However, if we sum up the memory usage of all running processes, we can come up with a conclusion that only 2.5 GB of memory is actually used.

Where are the rest 5 GB? Neither the Task Manager nor the Resource Monitor is able to answer this question.

To understand what is going on with memory, we need to use the RamMap tool.

Download the tool from the Microsoft website (https://technet.microsoft.com/en-us/library/ff700229.aspx) and run it with the administrator privileges.

Then, on the Use Counts tab,  we can see that the Driver Locked object use 5.4 GB

This is the memory the hypervisor occupies and distributes between other virtual machines using the balloon driver. It means that the hypervisor host does not have enough memory.

We can see the current VM memory statistics in Hyper-V by separate performance counters in the Performance Monitor:

• Hyper-V Dynamic Memory –> Guest Visible Memory
• Hyper-V Dynamic Memory –> Physical Memory

To disable this behavior, the hypervisor administrator must disable the Enable Dynamic Memory option in the Hyper-V settings of the VM.

If we use the VMWare ESXi host, we can reserve more memory for this virtual machine in the Resource Settings or reserve all memory – Reserve all guest memory (All locked).

[Confused or stuck in between? We are available 24*7]

Conclusion

To conclude, memory overcommit is a hypervisor feature that allows us to allocate to virtual machines more memory than is available on a physical host. Today, we saw how our Support Techs go about detecting Memory Overcommit in the Guest OS.