Virtualization matters because a virtual machine is not just 'another OS instance,' but a tool for isolation, multi-tenancy, and operational risk management.
In practice, the chapter helps you choose an isolation level and understand the price of the hypervisor: its impact on density, security, noisy neighbors, and latency-sensitive workloads.
In interviews and design discussions, it gives you a clear frame for comparing VMs, bare metal, and containers through consequences rather than slogans.
Practical value of this chapter
Isolation boundaries
Helps select isolation level with clear impact on security and workload density.
Performance overhead
Encourages explicit accounting for virtualization cost in latency-sensitive systems.
Platform manageability
Shows where VM-based environments remain preferable for control and compatibility.
Interview comparison
Provides clear decision criteria when comparing VMs and containers.
Source
Virtualization
Definition of virtualization, types and key approaches.
Virtualization allows you to run multiple isolated environments on a single physical server. For a VM, this means multiple guest OSes on top of shared hardware and a hypervisor.
What types of virtualizations are there?
Hardware virtualization
Creating virtual machines with separate guest operating systems.
Virtualization at the OS level
Containers share the kernel but isolate processes and the file system.
Network virtualization
Virtual networks, switches and balancers on top of the physical network.
Storage virtualization
Logical volumes and disk distribution between VMs.
Virtualization for VM
Full virtualization
The guest OS runs without modifications, the hypervisor emulates the hardware.
Paravirtualization
The guest OS knows about the hypervisor and optimizes calls.
Hardware-accelerated
Uses CPU support (eg VT-x/AMD-V) to improve performance.
Type 1 (bare-metal)
The hypervisor runs directly on the hardware and manages the VM.
Type 2 (hosted)
The hypervisor runs on top of the host OS and uses its drivers.
In practice, Type 1 hypervisors are more often used in clouds, and Type 2 on workstations.
VM virtualization approaches compared
Full virtualization
- Guest OS: Guest OS runs without modifications.
- Performance: Higher CPU and I/O overhead due to emulation paths.
- Compatibility: High compatibility, including many legacy systems.
- Typical usage: Compatibility-heavy workloads, labs, uncommon guest OSes.
Paravirtualization
- Guest OS: Guest OS/drivers are hypervisor-aware.
- Performance: Faster than pure emulation due to optimized call paths.
- Compatibility: Requires paravirtualized interfaces/drivers.
- Typical usage: Network and disk I/O acceleration in VM environments.
Hardware-accelerated
- Guest OS: Guest OS usually runs unmodified.
- Performance: Best production balance between isolation and speed.
- Compatibility: Broad support when VT-x/AMD-V is available.
- Typical usage: Cloud platforms and most production VM clusters.
Common production pattern: hardware-accelerated VMs plus paravirtualized network and disk drivers.
Real systems by virtualization type
Full virtualization
- QEMU in TCG mode (emulation without VT-x/AMD-V).
- Legacy use cases in VMware Workstation and VirtualBox for older guest OSes.
Chosen when compatibility is the main goal rather than maximum throughput and density.
Paravirtualization
- Xen PV (paravirtualized guests).
- KVM/QEMU + virtio for paravirtualized network and block devices.
- VMware VMXNET3 and PVSCSI as paravirtualized I/O drivers.
In practice, often used as a hybrid I/O layer on top of hardware-accelerated VMs.
Hardware-accelerated
- KVM (Linux), VMware ESXi, Microsoft Hyper-V, Xen HVM.
- Google Compute Engine, AWS Nitro, and Azure VM as cloud implementation examples.
Default path for production due to strong performance/isolation trade-off.
Multiple VMs on one host
The hypervisor distributes CPU, memory, network and disk between virtual machines, providing isolation.
The hypervisor virtualizes CPU, memory, network, and disk, creating isolated VMs.
Virtual machines inside host
VM 1
- Guest OS
- Nginx
- App A
VM 2
- Guest OS
- API
- Worker
VM 3
- Guest OS
- DB
- Cache
All VMs share one host's resources but stay isolated at guest OS and hypervisor levels.
How the request reaches nginx inside the VM
The request path passes through the host network interface, the hypervisor virtual switch, the guest OS and the service inside the VM.
Request path to nginx inside the VM
Request path: internet → host → hypervisor → VM → service
External
Layer 1Host
Layer 2Hypervisor
Layer 3VM
Layer 4Service
Layer 5Active step
Click "Start" to walk through the request path.
Why is it important to know virtualization
- VMs provide isolation and ease of migration of services between hosts.
- Performance depends on hypervisor, I/O and allocated resources.
- Network paths within a VM add latency, which is important to consider in SLAs.
- Scaling is often built around the VM as the unit of deployment.
- Understanding VM helps you estimate the cost and density of services.
Related chapters
- Why is fundamental knowledge needed? - sets the context for how hardware and OS limits shape virtualization choices.
- Operating system: overview - covers user space/kernel space boundaries that are essential for hypervisor reasoning.
- Linux: architecture and popularity - explains the host OS baseline used by most VM and cloud infrastructures.
- Modern Operating Systems (short summary) - deepens scheduling, memory, and I/O concepts that define VM efficiency.
- Containerization - helps compare VM and container isolation to choose the right deployment model.
- Why know Cloud Native and 12 factors - connects virtualization with cloud-native operating models and delivery practices.
- Kubernetes Fundamentals (v1.35): Architecture, Objects, and Core Practices - shows how container orchestration is typically run on top of VM infrastructure.
- RAM and persistent storage - adds memory and storage latency constraints that strongly affect VM workloads.