VMware ESXi and vSphere Cluster Management
Memory Virtualization in VMware ESXi Explained
Learn how the ESXi VMkernel virtualizes host memory, maps guest addresses to machine memory, isolates VMs, and supports concurrent workloads.
Memory virtualization is the mechanism that lets multiple virtual machines use one physical server safely. VMware ESXi presents each virtual machine with its own memory environment while the ESXi VMkernel controls how that environment is backed by physical RAM.
This lesson follows the path from an application address inside a guest operating system to the actual machine memory in the ESXi host. It also explains why guest memory is not the same thing as host physical memory.
What memory virtualization accomplishes
A physical server has a finite amount of RAM. If operating systems were given unrestricted access to that RAM, one operating system could overwrite another operating system's data, and the hypervisor itself could be damaged. A hypervisor must therefore create an abstraction between each guest and the physical hardware.
Memory virtualization is a hypervisor-provided abstraction that gives a virtual machine an isolated memory environment backed by host memory managed by ESXi. It is more than dividing RAM into fixed partitions. The VMkernel can maintain separate address spaces, translate memory references, control allocation, and change which host pages back a virtual machine's memory as operating conditions change.
- Isolation: One VM cannot normally read or modify another VM's memory.
- Concurrent execution: Several VMs can run at the same time on one host.
- Controlled allocation: VM memory is assigned and managed according to configuration and host resource conditions.
- Consistent guest model: Each guest OS sees a usable physical-memory model without needing to understand the host's hardware layout.
With simple fixed partitioning, each workload would receive a permanently assigned section of RAM. Virtualization instead allows the VMkernel to manage memory as a host resource while preserving an independent memory view for every VM.
The VMkernel and ESXi host memory
The ESXi host is the physical server running ESXi. Its actual RAM is called machine memory. The VMkernel is the ESXi hypervisor kernel responsible for managing host hardware resources, including machine memory.
Installed RAM is not entirely available for assignment to virtual machines. ESXi retains some memory for the VMkernel, device handling, management functions, and other internal operations. The remaining managed memory can be used to back virtual machines according to their configured memory and the host's current scheduling and memory conditions.
This distinction is important when reading capacity figures:
- Total host RAM is the physical memory installed in the server.
- ESXi-consumed memory is used by ESXi and its internal functions.
- VM-available managed memory is the portion that can support virtual-machine memory.
- Configured VM memory is the amount of memory presented to each VM in its virtual hardware configuration.
- Current workload use is the memory actively needed by applications and the guest OS at a particular time.
The three vSphere memory layers
Memory addresses have meaning only within a particular address space. In a virtualized system, at least three memory layers must be distinguished.
| Memory layer | Presented to | Managed by | Primary purpose | Relationship to the next layer |
|---|---|---|---|---|
| Guest operating system virtual memory | Applications and processes in the guest | Guest operating system | Provides each process with an application-facing virtual address space | Guest OS translates or maps it to guest physical memory |
| Guest operating system physical memory | Guest operating system | Virtual machine platform with VMkernel control | Represents the physical RAM that the VM appears to own | VMkernel maps it to host machine memory |
| ESXi host machine memory | ESXi and the VMkernel | VMkernel | Represents actual physical RAM in the server | Provides the physical backing for VM memory and ESXi operations |
Guest virtual memory
Guest virtual memory is the address space that applications use through the guest operating system. For example, an application might request memory from a Windows or Linux guest. The application receives addresses that are meaningful inside that guest process, not addresses of physical RAM in the ESXi server.
Guest physical memory
Guest physical memory is the physical-memory representation presented to a particular VM. The guest OS treats this layer as its machine memory. It may manage pages, page tables, and allocation within this view just as it would on a physical computer.
Guest physical addresses are not the same as host machine addresses. A guest OS can refer to a guest physical address, but it does not thereby obtain permission to access an arbitrary location in the ESXi server's RAM.
Host machine memory
Machine memory is the actual physical RAM controlled by the VMkernel. The VMkernel decides which host memory backs guest physical pages and enforces the boundaries between VMs and ESXi.
Address translation and mapping
A useful conceptual path is:
Application virtual address
↓ guest OS translation
Guest physical address
↓ VMkernel and virtual-machine memory mapping
ESXi host machine address
Suppose an application accesses a virtual address such as 0x00400000. The guest operating system manages the application's virtual address space and translates that reference to a guest physical page. The VMkernel then maps the guest physical page to a page in host machine memory that it controls.
The exact implementation can use hardware-assisted address translation and other ESXi mechanisms, but the architectural rule remains the same: the guest's address spaces are separate from the host's physical address space. The guest receives a continuous and usable memory view even though the VMkernel independently controls the host pages that provide its backing.
This is why a guest OS does not directly control arbitrary host RAM. Direct access would defeat isolation and could let a faulty or malicious guest corrupt ESXi or another VM.
Memory isolation between virtual machines
Each VM receives an independent guest-physical memory view. VM A may have a guest physical address such as page 100, and VM B may also have a guest physical page 100, but those references belong to different VM address spaces. They do not identify the same memory merely because the numbers match.
The VMkernel controls the mappings from each VM's guest physical pages to host machine pages. It validates memory accesses and prevents a normal guest access from being translated into another VM's pages or ESXi's protected memory.
Memory isolation is both:
- A security boundary: one VM cannot inspect another VM's secrets through ordinary memory access.
- A stability boundary: a guest memory error is prevented from directly overwriting another guest or the hypervisor.
| Component | Memory responsibility | What it can see | What it cannot directly access |
|---|---|---|---|
| Application | Requests and uses memory through its guest process address space | Its own guest virtual memory | Another process's protected memory, guest physical memory directly, or ESXi host hardware |
| Guest operating system | Manages processes, virtual memory, and the VM's apparent physical memory | Guest virtual memory and its own guest physical memory view | Arbitrary host machine memory or another VM's memory |
| Virtual machine platform and VMkernel | Maps guest memory, enforces isolation, and manages host backing | VM memory mappings and host machine memory under its control | Physical resources outside the host's permitted hardware and management boundaries |
| ESXi host hardware | Stores data in actual physical RAM | Machine-memory locations addressed by the host system | It does not independently understand guest application address spaces |
How several VMs run concurrently
Consider an ESXi host with 128 GB of installed RAM. Assume that ESXi uses part of that RAM for its own operations. Two VMs are configured with 32 GB and 48 GB of guest memory.
- Each guest OS sees its assigned memory as its own physical memory.
- The first VM cannot address the second VM's guest physical pages.
- The VMkernel tracks the memory needed by both VMs and maps their guest pages to host machine pages.
- The amount of memory actively used by applications can be lower than each VM's configured memory.
Configured memory describes the virtual hardware presented to a VM; it does not mean that an application is currently using every byte. Similarly, host memory currently associated with a VM is a runtime resource measurement, not simply a duplicate of the VM's configured setting.
Application memory request example
- A process asks its guest operating system for additional memory.
- The guest OS assigns addresses in the process's guest virtual memory.
- The guest OS manages the corresponding guest physical pages supplied by the VM's virtual hardware.
- The VMkernel maps those guest physical pages to available host machine memory under ESXi control.
- The application uses the memory without needing to know which host RAM locations back it.
Observing the model in vSphere
Use the vSphere Client's VM hardware settings to identify the amount of memory configured for a VM. Treat this value as the guest memory presented by the virtual hardware, not as a measurement of an application's current use or a complete explanation of host allocation.
For the host, use the available summary or performance views to compare total host memory, memory consumed by ESXi, and memory associated with running VMs. Interface labels vary by vSphere version, so the purpose of the exercise is to compare the layers rather than memorize a particular screen.
Common misunderstandings and troubleshooting
All installed RAM can be assigned to VMs
Symptom: An administrator expects every installed gigabyte to be exclusively assignable to virtual machines.
Cause: ESXi also needs managed machine memory for the VMkernel and internal operations.
Correction: Separate total host RAM, ESXi memory use, and memory available to support VMs.
Guest memory is host physical memory
Symptom: A learner treats a memory address or capacity shown inside the guest OS as a direct host physical address.
Cause: Guest physical memory has been confused with ESXi host machine memory.
Correction: Trace the three layers: guest virtual memory, guest physical memory, and host machine memory.
VMs on the same host can inspect each other's RAM
Symptom: A learner expects one VM to read another VM's memory because both share a physical server.
Cause: The VMkernel's per-VM address spaces and mapping controls have not been understood.
Correction: Emphasize that matching guest physical addresses in two VMs are still in separate domains, and the VMkernel enforces isolation.
Configured memory totals exceed host RAM
Symptom: The configured memory of several VMs appears to exceed readily available host physical RAM.
Possible cause: The environment may be using memory overcommitment, a condition in which total configured VM memory exceeds immediately available host physical RAM.
Correction: Treat overcommitment as a separate memory-management topic. Examine actual host memory pressure and monitoring data before changing VM allocations.
Scope and next concepts
The basic memory-virtualization model explains abstraction, address translation, concurrent operation, and isolation. It does not by itself describe every way ESXi responds when demand is high.
Follow-on topics include:
- Memory overcommitment
- ESXi memory reclamation techniques
- VM memory reservations, limits, and shares
- Host memory performance monitoring
- Virtual machine resource isolation
For comparison, CPU virtualization and storage virtualization apply similar abstraction ideas to different resources. Permissions and access control provide another, separate layer of protection around who may configure or inspect virtual infrastructure.
Exam-relevant summary
- The VMkernel is the ESXi component that manages host machine memory.
- Machine memory means the physical RAM installed in and controlled on the ESXi host.
- Guest virtual memory is the application-facing address space managed by the guest OS.
- Guest physical memory is the physical-memory model presented to one VM.
- Guest physical addresses are not direct host machine addresses.
- The conceptual translation path is application virtual address to guest physical address to host machine address.
- Memory virtualization enables isolation, concurrent VM execution, controlled allocation, and a consistent guest memory model.
- Some host memory is retained for ESXi, so total installed RAM is not identical to VM-available memory.
- Configured VM memory is not the same as current application memory use.
- Memory overcommitment is a related topic, not the definition of memory virtualization.
For a concise reference to the central abstraction and mapping model, see Memory Virtualization Explained.