Virtualizing RAM
CPU virtualization gets most of the attention, but memory virtualization is equally complex. When a hypervisor creates a VM with "4 GB of RAM," it doesn't necessarily allocate 4 GB of physical RAM immediately. Instead, it maintains a mapping between the VM's view of memory (called Guest Physical Addresses, or GPA) and actual machine memory (Host Physical Addresses, or HPA).
Modern CPUs have hardware support for this two-level address translation called Extended Page Tables (EPT) on Intel or Rapid Virtualization Indexing (RVI) on AMD. Without hardware support, the hypervisor had to maintain "shadow page tables" in software — a significant overhead. With EPT/RVI, the CPU's Memory Management Unit (MMU) handles the GPA→HPA translation directly in hardware, making memory access nearly as fast as on bare metal.
Memory Overcommit and Ballooning
Hypervisors can overcommit memory — promise more RAM to VMs than physically exists, betting that not all VMs will use their full allocation simultaneously. This is the same principle as airline overbooking.
When physical memory runs low, the hypervisor uses a balloon driver (the virtio-balloon driver mentioned earlier) to reclaim memory from VMs that aren't using it:
- The hypervisor tells the balloon driver inside a VM: "Inflate — allocate 512 MB of your guest RAM."
- The balloon driver allocates 512 MB inside the guest, making the guest OS think that memory is in use.
- The hypervisor then reclaims those physical pages and gives them to a different VM that actually needs them.
- When pressure eases, the balloon deflates and the guest gets its memory back.
Key Point: Memory ballooning is transparent to applications but not to the guest OS — the guest OS sees its available memory shrink and may start swapping to disk if the balloon inflates too aggressively. This is a common source of mysterious performance degradation in virtualized environments: the VM's memory metrics look fine from the outside (the hypervisor reports the VM has 8 GB), but inside the guest, the balloon has consumed 3 GB and the OS is swapping. Always monitor both the hypervisor-level memory allocation and the guest-level free memory and swap usage.