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...

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:

• Memory Swap In Rate: The rate at which memory is being swapped in from the disk.
• Memory Swap Out Rate: The rate at which memory is being swapped out to the disk.
• Swapped: The total amount of data that is sitting inside the .vswp hypervisor-level swap file. However, this doesn't tell you anything about the current...

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...

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...