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 layerPresented toManaged byPrimary purposeRelationship to the next layer
Guest operating system virtual memoryApplications and processes in the guestGuest operating systemProvides each process with an application-facing virtual address spaceGuest OS translates or maps it to guest physical memory
Guest operating system physical memoryGuest operating systemVirtual machine platform with VMkernel controlRepresents the physical RAM that the VM appears to ownVMkernel maps it to host machine memory
ESXi host machine memoryESXi and the VMkernelVMkernelRepresents actual physical RAM in the serverProvides 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.
ComponentMemory responsibilityWhat it can seeWhat it cannot directly access
ApplicationRequests and uses memory through its guest process address spaceIts own guest virtual memoryAnother process's protected memory, guest physical memory directly, or ESXi host hardware
Guest operating systemManages processes, virtual memory, and the VM's apparent physical memoryGuest virtual memory and its own guest physical memory viewArbitrary host machine memory or another VM's memory
Virtual machine platform and VMkernelMaps guest memory, enforces isolation, and manages host backingVM memory mappings and host machine memory under its controlPhysical resources outside the host's permitted hardware and management boundaries
ESXi host hardwareStores data in actual physical RAMMachine-memory locations addressed by the host systemIt 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

  1. A process asks its guest operating system for additional memory.
  2. The guest OS assigns addresses in the process's guest virtual memory.
  3. The guest OS manages the corresponding guest physical pages supplied by the VM's virtual hardware.
  4. The VMkernel maps those guest physical pages to available host machine memory under ESXi control.
  5. 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.