Cloud Fundamentals
Intermediate 15 min read Cloud Fundamentals

Virtualization and Hypervisors

The machinery behind elastic compute

Hypervisors carve physical servers into isolated virtual machines. Types 1 and 2, hardware-assisted virtualization and container-based alternatives are what make the elastic cloud possible.

hypervisorvirtualizationKVMVMthin provisioningcontainer
Prerequisites: What is Cloud Computing?
Before we start

What you will learn

  • Explain the role of a hypervisor in a VM architecture
  • Compare Type 1 and Type 2 hypervisors
  • Position containers as an alternative to hardware virtualization
In 60 seconds

A hypervisor is a thin software layer that lets many isolated operating systems share one physical machine. It is the engine that turns one server into a rack of rented computers.

Introduction

What is this?

Virtualization lets a hypervisor run multiple isolated virtual machines (VMs) on one physical host, each with its own OS, virtual CPU, memory and disk. Type 1 (bare-metal) hypervisors (KVM, Hyper-V, VMware ESXi, Xen) run directly on hardware and power the public clouds. Type 2 hypervisors (VirtualBox, QEMU-with-KVM userspace) run on an existing OS and are common in dev labs. Containers virtualize the OS layer instead of the machine — shared kernel, isolated processes — trading isolation for density.

Motivation

Why do you need it?

  • Without hypervisors there is no 'on-demand compute': each app would need its own physical server.
  • Hardware-assisted CPU features let a VM run at near-native speed, making multi-tenancy practical.
  • A hypervisor's isolation boundary is the cloud's core trust primitive — guests must not see each other.
  • Understanding the layer explains why 'reboot the VM' sometimes help and sometimes means the host.
Think about it

Mental model

Imagine

An apartment building's walls and utility meters

Think of

A hypervisor on a host

Everyone lives close together, each unit is sealed from its neighbors, and each pays for its own metered usage — the building (hypervisor) enforces the boundaries and allocates shared infrastructure.

Mechanics

How it works

  • The hypervisor owns the host hardware and presents each VM a virtual CPU, memory, disk and network device.
  • Privileged operations (IDT, MMU, I/O) are caught and emulated or passed through with hardware assist.
  • The hypervisor isolates memory and enforces scheduling, so a crashing guest can't take neighbors down.
  • Snapshots and live migration read/write a VM's state — powering backups and host maintenance without downtime.
  • Containers skip this isolation, sharing the host kernel with namespace/cgroup sandboxing instead.

Type 1 hypervisor hosting multiple guest VMs.

Physical host
Type 1 hypervisor
Guest VMs
VM A, VM B, VM C
Real world

In production

  • Public clouds place thousands of KVM-based VMs on each host rack, live-migrating guests during host patching.
  • A DR business keeps legacy OS images as VMs in the cloud, storing snapshots on object storage for replay.
  • Dev laptops run VirtualBox (Type 2) for local environments that mirror cloud AMIs.
Guidelines

Best practices

  • Size VM families to workload, knowing that a 'large' VM is several physical cores with shared host resources.
  • Use snapshots for point-in-time copies, not long-term backups — they live with the host and cost storage.
  • Prefer managed machine images over hand-built guest OS so patching and security baselines are reproducible.
  • Choose containers for density on controlled workloads and VMs for stricter isolation or legacy images.
Watch out

Common mistakes

  • Assuming a snapshot is a backup — it is a state copy, often on the same failure domain.
  • Overcommitting memory/CPU on smaller clouds purely on paper ratios, inviting noisy neighbors.
  • Running workloads that need custom kernels in an unsupported virtualization setting.
  • Treating 'VM' and 'container' as interchangeable when isolation and security models differ.
Root cause analysis

Common issues

Error
Guest shows high steal/awkward idle CPU
Root cause

Host CPU heavily overcommitted by other tenants

Fix

Move to a less-contended size/family or a dedicated host for latency-critical work.

Error
Snapshots fill the volume
Root cause

Snapshotting a frequently-written disk grows the change-set continuously

Fix

Schedule snapshots around write quiet times and expire them on a lifecycle policy.

Error
Live migration stalls a replicated ringer
Root cause

Memory-write rates exceed migration speed for a large-hot VM

Fix

Plan maintenance windows, or use larger instance classes with higher network throughput for migrations.

When things break

Debugging tips

  • CPU spikes from 'System/Steal' time indicate host-level contention — you're sharing the physical core.
  • If a snapshot rollback fails, check you aren't rolling a disk with an active write-heavy workload.
  • When live-migration is disabled, host maintenance shows up as instanced reboots — the hypervisor isn't broken.
  • 'Balloon' or 'steal' metrics are the correct place to look for noisy-neighbor impact.
Interviews

Interview checkpoint

Test yourself

Quick quiz

0/2
1

Which hypervisor type powers the public clouds?

2

A VM snapshot is a safe long-term backup strategy.

Go deeper

Official documentation

AWS — Amazon EC2 virtualization
docs
Linux KVM documentation
docs