Consumed Host Memory usage is defined as the amount of host memory that is allocated to the virtual machine, Active Guest Memory is defined as the amount of guest 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 virtual machine and providing hints to address potential performance issues.
This article helps answer these questions:
• Why is the Consumed Host Memory so high?
• Why is the Consumed Host Memory usage sometimes much larger than the Active Guest Memory?
• Why is the Active Guest Memory different from what is seen inside the guest operating system?
Terminology
The following terminology is used throughout this paper.
• Host physical memory refers to the memory that is visible to the hypervisor as available on the system.
• Guest physical memory refers to the memory that is visible to the guest operating system running in the virtual machine.
• Guest virtual memory refers to a continuous virtual address space presented by the guest operating system to applications. It is the memory that is visible to the applications running inside the virtual machine.
• Guest physical memory is backed by host physical memory, which means the hypervisor provides a mapping from the guest to the host memory.
• The memory transfer between the guest physical memory and the guest swap device is referred to as guest level paging and is driven by the guest operating system. The memory transfer between guest physical memory and the host swap device is referred
to as hypervisor swapping, which is driven by the hypervisor.
Memory Virtualization Basics
Virtual memory is a well-known technique used in most general-purpose operating systems, and almost all modern processors have hardware to support it. Virtual memory creates a uniform virtual address space for applications and allows the operating system and hardware to handle the address translation between the virtual address space and the physical address space. This technique not only
simplifies the programmer’s work, but also adapts the execution environment to support large address spaces, process protection, file mapping, and swapping in modern computer systems.
When running a virtual machine, the hypervisor creates a contiguous addressable memory space for the virtual machine. This memory space has the same properties as the virtual address space presented to the applications by the guest operating system. This allows the hypervisor to run multiple virtual machines simultaneously while protecting the memory of each virtual machine from being accessed by others. Therefore, from the view of the application running inside the virtual machine, the hypervisor adds an extra level of address translation that maps the guest physical address to the host physical address. As a result, there are three virtual
memory layers in ESX: guest virtual memory, guest physical memory, and host physical memory. Their relationships are illustrated in Figure 2 (a).
As shown in Figure 2 (b), in ESX, the address translation between guest physical memory and host physical memory is maintained by the hypervisor using a physical memory mapping data structure, or pmap, for each virtual machine. The hypervisor intercepts all virtual machine instructions that manipulate the hardware translation lookaside buffer (TLB) contents or guest operating system page tables, which contain the virtual to physical address mapping. The actual hardware TLB state is updated based on the separate shadow page tables, which contain the guest virtual to host physical address mapping. The shadow page tables maintain consistency with the guest virtual to guest physical address mapping in the guest page tables and the guest physical to host physical address mapping in the pmap data structure. This approach removes the virtualization overhead for the virtual machine’s normal memory accesses because the hardware TLB will cache the direct guest virtual to host physical memory address translations read from the shadow page tables. Note that the extra level of guest physical to host physical memory indirection is extremely powerful in the virtualization environment. For example, ESX can easily remap a virtual machine’s host physical memory to files or other devices in a manner that is completely transparent to the virtual machine.
Recently, some new generation CPUs, such as third generation AMD Opteron and Intel Xeon 5500 series processors, have provided hardware support for memory virtualization by using two layers of page tables in hardware. One layer stores the guest virtual to guest physical memory address translation, and the other layer stores the guest physical to host physical memory address translation. These two page tables are synchronized using processor hardware. Hardware support memory virtualization eliminates the overhead required to keep shadow page tables in synchronization with guest page tables in software memory virtualization.
Although the hypervisor cannot reclaim host memory when the operating system frees guest physical memory, this does not mean
that the host memory, no matter how large it is, will be used up by a virtual machine when the virtual machine repeatedly allocates and frees memory. This is because the hypervisor does not allocate host physical memory on every virtual machine’s memory allocation.
It only allocates host physical memory when the virtual machine touches the physical memory that it has never touched before. If a virtual machine frequently allocates and frees memory, presumably the same guest physical memory is being allocated and freed again and again. Therefore, the hypervisor just allocates host physical memory for the first memory allocation and then the guest reuses the same host physical memory for the rest of allocations. That is, if a virtual machine’s entire guest physical memory (configured memory) has been backed by the host physical memory, the hypervisor does not need to allocate any host physical memory for this virtual machine any more.
Memory Reclamation in ESX
ESX supports memory overcommitment from the very first version, due to two important benefits it provides:
- with memory overcommitment, ESX ensures that host memory is consumed by active guest memory as much as possible
- With memory overcommitment, each virtual machine has a smaller footprint in host memory usage, making it possible to fit more virtual machines on the host while still achieving good performance
Príspevky
Žiadne komentáre:
Zverejnenie komentára