VMware ESXi and vSphere Cluster Management

VMware ESXi Memory Virtualization Explained

Learn how ESXi and the VMkernel manage host RAM, translate guest virtual and physical memory, isolate VMs, and monitor memory usage.

Memory virtualization is the mechanism that lets multiple virtual machines (VMs) use one ESXi server while each VM appears to have its own private RAM. To understand it, separate three memory views: guest virtual memory, guest physical memory, and ESXi host machine memory.

This distinction is important when configuring VM memory, interpreting performance metrics, planning host capacity, and troubleshooting memory pressure.

What Is ESXi Memory Virtualization?

ESXi is a bare-metal hypervisor. It runs directly on server hardware rather than inside another operating system. Its core virtualization component, the VMkernel, controls hardware resources such as processors, memory, storage, and networking.

Memory virtualization is the abstraction and controlled mapping of host RAM into isolated memory environments for VMs. The VMkernel decides how host machine memory is made available to each VM and prevents one VM from accessing another VM's memory.

Without virtualization, an operating system normally assumes it owns the computer's physical RAM. On a consolidated ESXi host, many guest operating systems must share the same finite RAM. The VMkernel provides each one with an independent, addressable memory environment while controlling the underlying host pages.

Why Memory Virtualization Is Needed

  • Several VMs can run on one physical server.
  • Each VM can run a separate guest operating system and applications.
  • Each guest can treat its assigned memory as private physical RAM.
  • The hypervisor can allocate, track, protect, and reclaim host memory without requiring applications to understand the physical server layout.

For example, two VMs might each be configured with 8 GB of memory on a host with 64 GB of installed RAM. Both guests see their own 8 GB physical-memory range. They do not see the other VM's memory or need to know where their pages are located in host RAM.

The VMkernel's Role in Memory Management

The VMkernel is the central authority for ESXi host memory. It manages the physical RAM installed in the server and maps that RAM to the memory presented to VMs.

Some installed memory is required by ESXi itself. VMkernel functions, management agents, device drivers, virtualization data structures, and other host services consume memory. Therefore, the full installed RAM amount cannot automatically be assigned to guest workloads.

  • Installed memory: physical RAM fitted in the ESXi server.
  • ESXi memory usage: memory needed by the VMkernel and host services.
  • Workload memory: memory that can be assigned to and used by VMs after host requirements are considered.

Memory management is centralized at the hypervisor layer. A guest operating system can manage memory inside its VM, but it does not directly allocate arbitrary host RAM or control another VM's memory.

The Three vSphere Memory Layers

Memory layer | Visible to | Managed by | Purpose | Maps to

Guest operating system virtual memory | Applications and the guest OS | Guest operating system | Provides application-facing address spaces | Guest physical memory

Guest operating system physical memory | Guest operating system | VMkernel presents it; guest OS manages its contents | Represents the RAM configured for the VM | Host machine memory

ESXi host machine memory | VMkernel and host hardware | VMkernel | Provides the actual physical RAM backing VM pages | Physical RAM locations in the server

The guest-visible layers are logical from the host's perspective. A VM can see a contiguous range of guest physical memory even when the corresponding pages occupy separate, non-contiguous locations in host RAM.

Guest Virtual Memory

Guest virtual memory is the address space that applications use inside a VM. Applications normally do not access physical RAM addresses directly. Instead, each process receives a virtual address space managed by the guest operating system.

When an application reads or writes a virtual address, the guest operating system and the processor's MMU (Memory Management Unit) translate that address into a guest physical address. The guest OS uses this layer for process isolation, shared libraries, protection, and its own paging behavior.

Guest virtual memory is therefore different from ESXi host allocation. An application can request memory using ordinary operating system APIs without knowing whether its pages are currently backed by adjacent host pages, different host pages, or memory affected by hypervisor management.

Guest Physical Memory Presented to a VM

Guest physical memory is the logical physical RAM presented to a VM by the hypervisor. If a VM is configured with 8 GB of memory, the guest OS normally detects approximately 8 GB of installed physical RAM, subject to the VM's hardware configuration and platform details.

From the guest OS perspective, this memory is its own physical RAM. The guest OS can divide it among kernel memory, application memory, caches, and other uses. However, the guest physical addresses do not directly identify locations in the ESXi server's physical RAM.

VMkernel presents a contiguous logical guest physical-memory range. That range is an abstraction: the host pages backing it do not need to form one continuous physical range.

Host Machine Memory

Host machine memory is the actual physical RAM installed in the ESXi server. It is the only layer in this model that represents real hardware memory locations.

VMkernel tracks which host pages are available, reserved for ESXi, assigned to VMs, actively used, or subject to memory-management actions. It then maintains mappings between guest physical pages and host physical pages.

For example, guest physical pages numbered 0, 1, and 2 may be backed by host pages located far apart in physical RAM. The guest still sees a normal contiguous memory range because the mapping is transparent to it.

Address Translation and Mapping

A memory access travels through more than one address layer:

  1. An application generates a guest virtual address.
  2. The guest operating system translates that address to a guest physical address.
  3. VMkernel and processor hardware translate the guest physical address to a host physical address.
  4. The server's memory hardware accesses the corresponding location in host RAM.

Step | Address or memory representation | Responsible component | Result

Application access | Guest virtual address | Application and guest operating system | A process requests or accesses an address in its virtual address space

Guest OS translation | Guest virtual address to guest physical address | Guest OS page tables and guest MMU behavior | The guest identifies a page in its presented physical-memory range

VMkernel and hardware-assisted translation | Guest physical address to host physical address | VMkernel and processor virtualization hardware | The hypervisor selects the actual host page backing the guest page

Host physical RAM access | Host physical address | Host memory controller and RAM hardware | Data is read from or written to server memory

Modern processors provide hardware-assisted memory virtualization. Technologies such as Intel Extended Page Tables (EPT) and AMD Rapid Virtualization Indexing (RVI), also called Nested Page Tables (NPT), help translate guest physical addresses to host physical addresses efficiently.

At a conceptual level, nested page tables add another translation structure beneath the guest operating system's page tables. The application and guest OS do not need to know that this additional mapping exists.

Memory Isolation and Protection

Each VM has an independent memory address space. The VMkernel enforces the boundary between these spaces by controlling which host pages each VM can map and access.

If two VMs use the same guest physical address value, those values belong to separate address spaces. The values do not automatically refer to the same host memory location.

Scope | Example | Who can access it | Isolation boundary

Application process memory | A process heap or code segment | The process and permitted guest OS components | Guest operating system process protection

Guest operating system memory | Guest kernel memory and page tables | The guest OS, subject to its own controls | Guest operating system protection

Virtual machine memory | The guest physical memory configured for one VM | That VM through its virtual hardware | VMkernel and processor virtualization controls

ESXi host memory | Physical RAM installed in the server | VMkernel and authorized host components | ESXi and hardware protection

This isolation provides both stability and security. A faulty guest kernel should not be able to overwrite another VM's memory, and an application in one VM should not be able to inspect the private memory of a different VM through ordinary memory access.

VM-to-VM isolation is different from process isolation inside a guest. The guest OS protects processes from one another, while the VMkernel protects complete VMs from one another and protects host memory from guest access.

How Multiple VMs Operate Concurrently

Memory virtualization allows many VMs to operate on one host because each VM receives a logical memory environment rather than direct ownership of a fixed physical section of RAM.

Host capacity remains finite. VM configuration, current workload demand, VMkernel overhead, and other host requirements must all be considered. Configured memory is the amount presented to a VM; it is not a promise that every byte corresponds to a permanent contiguous range of host RAM.

Memory overcommitment is a related resource-management concept in which the total configured VM memory is greater than the host's immediately available physical RAM. ESXi can use memory-management mechanisms to handle demand, but overcommitment does not change the basic three-layer address model or remove the need for capacity planning.

Example: Translating an Address in an 8 GB VM

Consider a VM configured with 8 GB of memory:

  1. An application accesses a virtual address supplied by the guest operating system.
  2. The guest OS uses its page tables to map that address into a page within the VM's 8 GB guest physical-memory range.
  3. VMkernel maintains a mapping from that guest physical page to a host physical page.
  4. The processor's hardware-assisted virtualization features help perform the guest-to-host translation.
  5. The host memory hardware accesses the selected location in the ESXi server's RAM.

The application sees only its virtual address. The guest OS sees guest physical RAM. VMkernel controls the final mapping to host machine memory.

Example: Two VMs on One 64 GB Host

Suppose an ESXi host has 64 GB of installed RAM and runs VM-A and VM-B, each configured with 8 GB.

  • VM-A sees an independent 8 GB guest physical-memory range.
  • VM-B sees a different independent 8 GB guest physical-memory range.
  • A guest address such as a particular hexadecimal value can appear in diagnostic output from both VMs.
  • The matching address values are interpreted within different VM address spaces.
  • VMkernel maps each VM's guest physical pages separately and prevents cross-VM access.

The two VMs may use shared host RAM capacity, but they do not share unrestricted access to one another's memory.

Configured Memory Versus Current Host Backing

A VM configured with 8 GB is presented with a contiguous logical guest physical-memory range. That does not mean VMkernel reserves one permanently contiguous 8 GB block of physical host RAM.

Host backing can consist of pages at different physical locations. The mapping layer makes this arrangement transparent to the guest OS and applications. This is why a VM's configured memory value must not be interpreted as a host physical address range.

VMkernel Memory Usage Versus VM Memory

Two broad categories appear in host memory planning:

  • VMkernel and host-service memory: memory used by ESXi management agents, drivers, virtualization structures, and other host functions.
  • VM memory: memory configured for VMs and the portion currently backed or actively used according to workload and platform behavior.

Because ESXi requires memory to operate, installed RAM and memory available for VM workloads are not identical values. Capacity planning must account for host overhead before comparing VM requirements with host capacity.

Configure VM Memory in the vSphere Client

  1. Open the VM in the vSphere Client.
  2. Open the VM's hardware or configuration settings.
  3. Locate the Memory setting.
  4. Set the amount of memory to present to the guest operating system.
  5. Apply the change according to the VM power-state and hot-add requirements shown by the client.

The configured value represents guest-visible physical RAM. It is not a direct, fixed physical address range on the ESXi host.

Monitor Memory in vSphere

At the host level, review memory capacity and utilization in the vSphere Client. At the VM level, compare configured memory with available active or consumed memory metrics where provided.

Metric names, definitions, and availability can vary by vSphere version and licensing. Always check the metric's scope before drawing a conclusion: a guest OS metric describes the guest's view, while a host or VMkernel metric describes ESXi resource management.

Optional Advanced Observation with esxtop

Where an ESXi shell or SSH session is permitted, esxtop provides an observational view of ESXi statistics:

esxtop
m

The first command launches the utility. The m command selects the memory view. This tool is optional for learning the basic model; it is most useful when correlating host and per-VM statistics during troubleshooting.

Troubleshooting Common Memory Confusion

A VM's configured memory is assumed to be one contiguous host block

The likely problem is confusing guest physical memory with host machine memory. Reinforce that the VM sees a contiguous logical range, while VMkernel maps its pages to host locations that do not need to be contiguous.

Two VMs show identical memory addresses

The same address value can exist independently in separate guest address spaces. Compare the VM context and the guest-to-host mappings rather than treating the numeric address alone as a global host address.

Total VM configuration is compared directly with installed RAM

Include memory used by VMkernel, management agents, drivers, and virtualization functions. Installed capacity is not the same as memory available to guest workloads.

A guest paging problem is automatically blamed on ESXi

Diagnose from the correct layer. First examine application and guest OS paging behavior, then review VM configuration and guest-visible memory, and finally investigate ESXi host memory contention and reclamation indicators.

Exam-Relevant Notes

  • VMkernel is the ESXi component that manages host physical memory.
  • Guest virtual memory is managed by the guest operating system for applications and processes.
  • Guest physical memory is the logical RAM presented to the VM.
  • Host machine memory is the actual physical RAM installed in the ESXi server.
  • The guest physical address space does not need to match a contiguous range of host physical RAM.
  • VMkernel maintains guest-physical-to-host-physical mappings.
  • Intel EPT and AMD RVI/NPT are examples of hardware-assisted nested page-table support.
  • Hypervisor memory isolation prevents one VM from reading or modifying another VM's memory.
  • ESXi host overhead must be included in memory capacity planning.
  • Memory overcommitment is a resource-management policy related to, but distinct from, the basic address-translation model.

Summary

ESXi memory virtualization separates what software sees from where data physically resides. Applications use guest virtual addresses, the guest OS translates them to guest physical addresses, and VMkernel maps those guest pages to host machine memory. Hardware-assisted translation helps perform this mapping efficiently.

This layered design lets many VMs run concurrently, gives each VM an isolated memory environment, and allows ESXi to manage finite host RAM centrally. Correctly distinguishing configured guest memory, current host backing, and VMkernel overhead is essential for administration and troubleshooting.

For broader ESXi foundations, see VMware ESXi Online Course. Related administration topics include Admission Control Explained, Add Virtual Hardware to VM, and Assign Permissions.