Virtualization Concepts

In the architecture of virtualization, two distinct realms coexist: the host and the guest. The host possesses the physical hardware—real processors, tangible memory modules, actual storage devices. The guest exists as an abstraction, convinced it has exclusive access to hardware that, in truth, is shared, virtualized, and carefully managed by an intermediary.

This relationship defines everything in virtualization. How resources are allocated, how performance is achieved, how isolation is maintained, how problems are debugged—all depend on understanding the intricate dance between host and guest.

For engineers deploying virtual infrastructure, troubleshooting performance problems, or designing cloud-native applications, the host-guest relationship isn't abstract theory—it's the foundation of daily work.

Let's establish precise definitions for these fundamental concepts:

The Host System:

The host is the physical machine and its associated software that provides resources for virtual machines. Depending on the hypervisor architecture, the host may include:

• Physical hardware — The actual CPU, RAM, storage, and network interfaces
• Host operating system — Present in Type 2 hypervisors (like VirtualBox or VMware Workstation)
• Hypervisor/VMM — The Virtual Machine Monitor that manages guest VMs

The Guest System:

The guest is the virtual machine and everything running within it:

• Guest operating system — A complete OS (Windows, Linux, BSD) running within the VM
• Guest applications — Programs running on the guest OS
• Virtual hardware — The virtualized CPU, memory, storage, and devices presented to the guest

Terminology Precision:

The industry uses several related terms that are sometimes confused:

These terms vary by vendor and technology, but the underlying concepts remain consistent: one entity has privileged control over physical resources, and others operate within controlled sandboxes.

The fundamental purpose of virtualization is resource sharing—enabling multiple guests to use the same physical hardware efficiently. This requires careful management of ownership, allocation, and access.

The Resource Flow:

Physical resources flow from hardware through the hypervisor to guests in a carefully controlled hierarchy:

Resource Allocation Models:

Hypervisors use several models for resource allocation, each with tradeoffs:

1. Dedicated Allocation (Partitioning): Physical resources are exclusively assigned to specific VMs. A 4-vCPU VM might receive 4 physical cores that no other VM can use. This provides predictable performance but reduces flexibility and utilization.

2. Shared Allocation (Time-Slicing): Physical resources are shared among VMs through time-division multiplexing. The hypervisor scheduler ensures fair access. Higher utilization, but performance varies based on total demand.

3. Overcommitted Allocation: The hypervisor presents more virtual resources than physically exist. Combined virtual memory might exceed physical RAM; total vCPUs might exceed physical cores. This works when VMs don't simultaneously use all resources but can cause severe issues under contention.

4. Reserved/Limited Allocation: VMs receive guaranteed minimums (reservations) and enforced maximums (limits). A VM might reserve 2 GB RAM (always available) with a limit of 8 GB (can expand if resources are available). This balances predictability with flexibility.

CPU virtualization presents one of the most critical host-guest interfaces. The hypervisor must efficiently share processor time among guests while maintaining the illusion of dedicated CPUs.

vCPU Scheduling:

A virtual CPU (vCPU) represents a logical processor visible to the guest OS. The guest schedules its processes onto vCPUs exactly as it would schedule onto physical cores. However, vCPUs are themselves scheduled onto physical CPUs (pCPUs) by the hypervisor.

This creates a two-level scheduling hierarchy:

1. Guest scheduler — Places guest processes onto vCPUs
2. Hypervisor scheduler — Places vCPUs onto pCPUs

vCPU to pCPU Mapping:

The vCPU Sizing Problem:

How many vCPUs should a VM have? This question has no universal answer—it depends on workload characteristics:

• Single-threaded workloads — Benefit little from multiple vCPUs; adding vCPUs wastes resources
• Multi-threaded workloads — Scale with vCPUs up to a point
• I/O-bound workloads — Often need fewer vCPUs than CPU-bound workloads
• Real-time workloads — May need dedicated (pinned) vCPUs

A critical principle: More vCPUs is not always better. A VM with too many vCPUs may experience scheduling latency while waiting for all vCPUs to be available (for gang scheduling) or cache thrashing as vCPUs bounce between cores.

CPU Overcommitment Ratios:

The ratio of total vCPUs to physical cores determines overcommitment:

Overcommitment works because most VMs don't fully utilize their vCPUs simultaneously. However, when multiple VMs need CPU concurrently, performance degrades.

Memory virtualization introduces an additional address translation layer, creating a two-dimensional address space where understanding the distinction between guest addresses and host addresses is crucial.

Address Space Terminology:

• Guest Virtual Address (GVA) — The address space seen by guest applications
• Guest Physical Address (GPA) — The "physical" memory seen by the guest OS (actually virtual)
• Host Physical Address (HPA) — The actual physical RAM addresses

Two-Level Address Translation:

Translation Mechanisms:

Shadow Page Tables (Software Approach):

Before hardware support, hypervisors maintained "shadow" page tables that combined both translations:

• Hypervisor intercepts guest page table modifications
• Creates shadow tables mapping GVA directly to HPA
• Hardware uses shadow tables, guest doesn't know

Performance cost: High overhead for context switches and page faults

Extended Page Tables (EPT) / Nested Page Tables (NPT):

Intel EPT and AMD NPT provide hardware-accelerated two-level translation:

• Guest page tables (GVA → GPA) are used directly by hardware
• EPT/NPT tables (GPA → HPA) are managed by hypervisor
• Hardware walks both tables automatically

Performance benefit: Dramatically reduces hypervisor involvement

Memory Allocation to Guests:

Memory Reclamation Techniques:

When host memory is constrained, hyeprvisors use several techniques:

1. Balloon Driver: A driver in the guest that can be instructed to "inflate"—allocating memory within the guest that the host can then reclaim. The guest OS handles the pressure (paging, swapping) without knowing the true cause.

2. Content-Based Page Sharing (CBPS): Also known as Kernel Same-Page Merging (KSM) in Linux. Identical memory pages across VMs are merged, with copy-on-write semantics. Effective for VMs running similar operating systems.

3. Hypervisor Swapping: The hypervisor pages guest memory to disk. This is a last resort—extremely expensive compared to guest-level swapping because the hypervisor can't distinguish hot and cold pages.

4. Memory Compression: Compress infrequently accessed guest pages in RAM. Faster than swapping but adds CPU overhead.

I/O virtualization is often the most complex and performance-critical aspect of the host-guest relationship. Physical devices must be multiplexed among multiple guests, each expecting direct hardware access.

I/O Virtualization Approaches:

I/O Performance Comparison:

Beyond resource sharing, hosts and guests need coordination mechanisms—channels for management commands, status reporting, and cooperative operations.

Types of Communication Channels:

The Guest Agent Model:

Guest agents are essential for full-featured virtualization. They run as services/daemons within the guest and communicate with the hypervisor:

Common Guest Agent Capabilities:

• Graceful shutdown — Hypervisor requests shutdown; agent initiates OS shutdown sequence
• Time synchronization — Agent adjusts guest clock to match host
• File transfer — Copy files between host and guest without network
• Command execution — Run commands inside guest from external management tools
• Memory ballooning — Agent inflates/deflates balloon based on host requests
• Heartbeat monitoring — Agent reports guest is responsive
• Performance metrics — CPU, memory, disk utilization from guest perspective

Example Guest Agents:

The host-guest relationship includes critical isolation boundaries that prevent VMs from affecting each other or the host. Understanding these boundaries is essential for security and reliability.

Isolation Dimensions:

The VM Escape Problem:

A VM escape occurs when malicious code in a guest gains access to the host or other guests, breaking isolation. This represents the most severe virtualization security failure.

Historical VM Escape Vulnerabilities:

• CVE-2015-3456 (VENOM) — Floppy drive emulation bug in QEMU allowed arbitrary code execution on host
• CVE-2017-5715 (Spectre) — CPU speculation revealed information across isolation boundaries
• CVE-2020-3992 — VMware heap overflow allowed code execution on host

Defense-in-Depth for Isolation:

1. Minimize hypervisor attack surface — Run minimal services, disable unused features
2. Regular patching — Security updates for hypervisor and guest agents
3. Least privilege — VMs should have only necessary capabilities
4. Monitoring — Detect anomalous VM behavior
5. Defense layers — Even if VM isolated by hypervisor, add network isolation, storage isolation

The relationship between host and guest is the foundation of all virtualization technology. Let's consolidate the key insights:

What's Next:

With the host-guest relationship understood, we'll explore the benefits of virtualization—the compelling reasons organizations invest in virtualization technology despite its complexity. Understanding these benefits contextualizes every design decision we've discussed.