Although VMware vSphere uses various mechanisms to efficiently allocate memory, you might still encounter a situation where VMs are allocated with insufficient physical memory.

You should know how to monitor memory usage of both host machines and VMs. You should also know how to troubleshoot common memory performance problems, such as those involving a demand for memory.

VMs perform memory allocation in the same way an operating system handles memory allocation and deallocation. The guest operating system frees a piece of physical memory by adding memory page numbers to the guest free list.

The guest operating system's free list is not accessible to the hypervisor; thus, it is difficult for the hypervisor to know when to free the host physical memory and when the guest physical memory needs to be freed. The hypervisor is completely unaware of which pages are free or allocated to the guest operating system, and because of this, it cannot reclaim the host physical memory when the guest operating system frees guest physical memory.

So the VMware hypervisor relies on memory reclamation techniques to reclaim the host physical memory that is freed by the guest operating system. These are the memory reclamation techniques:

Excessive memory demand can cause severe performance problems for one or more VMs on an ESXi host. When ESXi is actively swapping from the memory of a VM to disk, the performance of that VM will degrade. The overhead of swapping a VM's memory to a disk can also degrade the performance of other VMs because the VM expects to be writing to RAM (speeds measured in nanoseconds), but it is unknowingly writing to disk (speeds measured in milliseconds).

The counters in vSphere Client for monitoring the swapping activity are as follows:

Ballooning is part of normal operations when memory is overcommitted. The occurrence of ballooning is not necessarily an indication of a resource-deficient infrastructure. The use of the balloon driver enables the guest to give up physical memory pages that are not being used. In fact, ballooning can be a sign that you're getting extra value out of the memory you have in the host.

However, if ballooning causes the guest to give up memory that it actually needs, performance problems can occur due to guest operating system paging.

In vSphere Web Client, use the Memory Balloon counter to monitor a host's ballooning activity. This counter represents the total amount of memory claimed by the balloon drivers of the VMs on the host. The memory...

The amount of memory VMkernel will try to keep free can be set through the Mem.MemMinFreePct parameter. MemMinFreePct determines the amount of memory that VMkernel should keep free. vSphere 4.1 introduced a dynamic threshold for the Soft, Hard, and Low states to set appropriate thresholds and prevent VM performance issues while protecting VMkernel. The different states, based on %pRAM, which is still free, determines what type of memory reclamation techniques would be used.

For MemMinFreePct, using a default value of 6 percent can be inefficient when 256 gigabytes, 512 gigabytes, or even 1 TB hosts are becoming more mainstream. Having a 6 percent threshold on 512 gigabytes results in 30 gigabytes idling most of the time. However, not all customers use large systems; some prefer to scale out rather than scale up. If you choose to scale out and have more servers with less RAM in each system, a 6 percent MemMinFreePct threshold might be suitable. To have the...

To troubleshoot memory performance in a VMware vSphere environment, you should monitor the memory performance very carefully. In this aspect, you should monitor the following counters:

A lot of the time, we assume that some very popular counters would be better to monitor memory performance. However, many times, it leads to something else. This means that these are not an indication of a memory performance issue. If this counter is combined with something else, then it may indicate performance degradation.

In this aspect, don't use two of the most popular counters just to understand whether the memory is under pressure or not:

Let me show you what they essentially indicate.

The Mem.consumed counter is the amount of memory consumed by one or all VMs. This is calculated as memory granted minus memory saved by sharing. Now the question is why we should not use this. The reason is that memory allocation will vary dynamically based on the VM's entitlement. It is important that a VM should get whatever it actually demands.

Similarly, Mem.vmmemctl is the amount of ballooned memory. This does not...

Both your host memory and VM memory can indicate that they are under pressure. But the main challenge to a VMware admin is how to determine that there is a memory performance issue.

There are a few things that a VMware admin should understand to confirm whether there is a memory performance issue, and they are:

Now if you wonder what is the Active Memory here in relation to Consumed Memory, let me tell you that Active Memory is the amount of memory that is actively used, as estimated by VMkernel, based on recently touched memory pages. For a VM, this is referred to the amount of guest physical memory that is actively used.

The ESXi host calculates Active Memory using the sum of all the active counters for all the powered-on VMs plus vSphere services on the host.

There could be another...

Often, you need to monitor VM and host memory usage; the good part about this is that VMware vSphere Client exposes two memory statistics in the Summary tab of a VM. These are Consumed Host Memory and Active Guest Memory.

Consumed Host Memory is the amount of host physical memory that is allocated to the VM. Please note that this value includes virtualization overhead as well.

Active Guest Memory is defined as the amount of guest physical memory that is currently being used by the guest operating system and its applications.

These two statistics are quite useful for analyzing the memory status of the VM and providing...

Virtualization causes an increase in the amount of physical memory required due to the extra memory needed by ESXi for its own code and data structures, and you need to know what are the best practice standards you have.

There are four basic principles that you should keep in mind:

Although VMware vSphere uses various mechanisms to efficiently allocate memory, you might still encounter a situation where VMs are allocated with insufficient physical memory.

You should know how to monitor memory usage of both host machines and VMs. You should also know how to troubleshoot common memory performance problems, such as those involving a demand for memory.

VMs perform memory allocation in the same way an operating system handles memory allocation and deallocation. The guest operating system frees a piece of physical memory by adding memory page numbers to the guest free list.

The guest operating system's free list is not accessible to the hypervisor; thus, it is difficult for the hypervisor to know when to free the host physical memory and when the guest physical memory needs to be freed. The hypervisor is completely unaware of which pages are free or allocated to the guest operating system, and because of this, it cannot reclaim the host physical memory when the guest operating system frees guest physical memory.

So the VMware hypervisor relies on memory reclamation techniques to reclaim the host physical memory that is freed by the guest operating system. These are the memory reclamation techniques:

Excessive memory demand can cause severe performance problems for one or more VMs on an ESXi host. When ESXi is actively swapping from the memory of a VM to disk, the performance of that VM will degrade. The overhead of swapping a VM's memory to a disk can also degrade the performance of other VMs because the VM expects to be writing to RAM (speeds measured in nanoseconds), but it is unknowingly writing to disk (speeds measured in milliseconds).

The counters in vSphere Client for monitoring the swapping activity are as follows: