Virtualization#
Virtual machines were the first abstraction that made server fleets manageable. A hypervisor runs on physical hardware; many isolated guest operating systems run on top. Mainframes had this in the 1960s; x86 virtualization arrived in the 2000s and changed everything below the application layer.
Virtualization is the ground floor of cloud computing.
flowchart TB
HW[Physical Server / Bare Metal]
HW --> Hypervisor
subgraph Hypervisor["Hypervisor (Type 1 or 2)"]
direction LR
VM1[VM 1<br/>Guest OS]
VM2[VM 2<br/>Guest OS]
VM3[VM 3<br/>Guest OS]
end
VM1 --> A1[App A]
VM2 --> A2[App B]
VM3 --> A3[App C]
Two Hypervisor Types#
The two architectural shapes for hypervisors. Type 1 runs directly on hardware, the host OS is the hypervisor. Type 2 runs as an application on top of a regular OS, slower but more convenient. Cloud providers run massive Type 1 fleets; desktops run Type 2.
Type 1 (bare-metal). Runs directly on hardware. The host OS is the hypervisor.
Type 2 (hosted). Runs as an application on top of a regular OS. Slower, more convenient.
Type |
Hypervisor |
Notes |
|---|---|---|
Type 1 (bare-metal) |
VMware ESXi |
Cloud-fleet default. |
Type 1 (bare-metal) |
Microsoft Hyper-V |
In Server mode. |
Type 1 (bare-metal) |
Citrix XenServer |
Xen-derived. |
Type 1 (bare-metal) |
KVM on Linux |
A kernel module that turns Linux into a hypervisor. |
Type 1 (bare-metal) |
Proxmox VE |
KVM + LXC under a management UI. |
Type 2 (hosted) |
VMware Workstation |
Desktop / lab use. |
Type 2 (hosted) |
Oracle VirtualBox |
Cross-platform, free. |
Type 2 (hosted) |
Parallels |
macOS host. |
Type 2 (hosted) |
QEMU (without KVM) |
Pure emulation, slow without acceleration. |
Cloud providers run massive Type 1 hypervisor fleets.
What Virtualization Solved#
The wins that justified the cost of an extra abstraction layer. Server consolidation packed underused apps onto fewer machines; hardware abstraction made physical failures recoverable; snapshots, clones, and live migration enabled operations impossible on bare metal.
Win |
Shape |
|---|---|
Server consolidation |
Many lightly-loaded apps on fewer physical machines. |
Hardware abstraction |
Replace a failed physical box; restore VMs to it. |
Snapshot / clone |
Save state; spin up identical copies. |
Live migration |
Move a running VM between hosts (vMotion). |
Resource isolation |
One app’s bug doesn’t crash another’s OS. |
Templated provisioning |
“Golden images” producible in minutes instead of days. |
Containers vs. VMs#
The two are often compared; they overlap less than people think.
Property |
Virtual Machine |
Container |
|---|---|---|
Isolation level |
Full OS, separate kernel |
Process; shared kernel |
Guest OS |
Yes (full image, GBs) |
No, inherits host kernel |
Boot time |
Seconds to minutes |
Sub-second |
Density per host |
10s |
100s-1000s |
Attack surface |
Hypervisor (smaller) |
Kernel + container runtime |
Compatibility |
Any OS / kernel version |
Same kernel as host |
Use case |
Multi-tenant, security boundary |
App packaging, density |
Modern systems run containers inside VMs: VMs for the security boundary; containers for the density.
Tools and Platforms#
The hypervisors and management stacks an operator may meet. VMware’s vSphere is the enterprise default; Hyper-V leads on Windows; KVM plus QEMU plus libvirt powers most Linux clouds; Proxmox packages the open stack; VirtualBox and friends cover desktop development.
Tool |
Role |
|---|---|
VMware |
vSphere / ESXi / vCenter; the enterprise default for decades. |
Microsoft Hyper-V |
Windows-stack default. |
KVM + QEMU + libvirt |
The Linux open-source stack; powers much of the cloud. |
Xen |
The original hypervisor under early AWS EC2. |
Proxmox VE |
KVM + LXC packaged for self-hosted virtualization. |
VirtualBox |
Desktop development VMs. |
Vagrant |
Declarative dev VMs (paired with VirtualBox / VMware / libvirt). |
Multipass |
Ubuntu VMs on macOS / Linux / Windows; lightweight cloud-init-friendly local VMs. |
Lima |
Linux VMs on macOS, often paired with containerd. |
OrbStack |
macOS-friendly virtualization. |
UTM |
macOS-friendly virtualization. |
Parallels |
macOS-friendly virtualization. |
Lightweight Modern VMs#
The line between VM and container is blurring:
Tool |
Role |
|---|---|
Firecracker (AWS) |
MicroVMs that boot in milliseconds; runs Lambda and Fargate. |
Kata Containers |
Containers wrapped in lightweight VMs for stronger isolation. |
gVisor |
User-space kernel between container and host; middle-ground isolation. |
WebAssembly (Wasm) |
A different abstraction entirely; tiny startup, sandboxed by design. |
Each is a different point on the isolation-vs-density curve.
Cloud-Init and Golden Images#
Two patterns that survived the move from on-prem virtualization to the cloud:
Pattern |
Shape |
|---|---|
Cloud-init |
A tool that runs on first boot to configure a VM from metadata (SSH keys, packages, files, scripts). Universal in cloud images. |
Golden images |
Pre-baked OS + app images, produced by Packer / image-builder. Booting is “ready in 30s” instead of “ready in 10min after package install”. |
Together they made VMs declarative enough to compose in Terraform / CloudFormation alongside the rest of the cloud.
Where Virtualization Sits in the Stack#
In 2026, most engineers don’t run hypervisors directly:
Surface |
What’s underneath |
|---|---|
Cloud VMs (EC2, Compute Engine, Azure VMs) |
Hide the hypervisor. |
Kubernetes nodes |
Usually cloud VMs running containers. |
Serverless |
Runs on hidden VMs (Firecracker etc.). |
Self-hosted homelabs |
Still use Proxmox / KVM / ESXi. |
Virtualization is mostly invisible; that doesn’t mean it isn’t there.
What Virtualization Didn’t Solve#
The gaps that invited the next waves. Application configuration still happened on top; provisioning at scale needed IaC; density was capped by full-OS overhead; cattle-versus-pets discipline was optional. Config management, cloud, IaC, and containers each closed a gap.
Gap |
Shape |
|---|---|
Application-level configuration |
VMs gave you a clean OS, not a configured app. Config management filled the gap. |
Provisioning at scale |
Spinning up 1000 VMs by hand was still slow. IaC (CloudFormation, Terraform) automated it. |
Density limits |
A VM still has a full OS; containers improved density 10×. |
Cattle vs. pets |
VMs could be either, depending on discipline. Containers plus orchestration forced the cattle model. |
The next steps, config management, cloud, IaC, containers, Kubernetes; each addressed one of these.