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

Here at Ibmi Media, as part of our Server Management Services, we regularly help our Customers to perform virtual machine related tasks.

In this context, we shall look into the steps to detect memory overcommit in the Guest OS.

More about 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 on Memory Overcommit? We can help you!]

How to go about 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 detecting Memory Overcommit in the Guest OS? We are available 24*7.]