Cloud
Virtualization and Hypervisors¶
Virtualization lets one physical server run many isolated virtual machines (VMs), each behaving like an independent computer. It is the foundation that makes cloud computing possible.
Applies to
These are general virtualization concepts that apply across platforms. Examples reference VMware ESXi, Microsoft Hyper-V, KVM/libvirt, Xen, and Proxmox, but the principles are the same everywhere. For how this connects to renting instances, see What Is Cloud Computing?.
What virtualization is — and why it underpins cloud¶
A modern server has far more CPU, memory, and disk than most single workloads need. Virtualization solves this by inserting a software layer that carves one physical machine into many virtual ones, each fully isolated from the others and from the host. Benefits:
- Consolidation — run many workloads on fewer physical machines, raising utilisation.
- Isolation — a crash, reboot, or compromise in one VM doesn't affect its neighbours.
- Abstraction — VMs are decoupled from specific hardware, so they can be moved, cloned, and resized.
This is exactly what a cloud provider needs: a giant pool of hardware sliced into on-demand, isolated, resizable units. Cloud instances are virtual machines (or containers) running on the provider's virtualization clusters.
Hypervisors: Type 1 vs Type 2¶
The software layer that creates and runs VMs is the hypervisor (or Virtual Machine Monitor). It allocates physical CPU, memory, and I/O to each VM and keeps them isolated. There are two types.
| Type 1 — bare-metal | Type 2 — hosted | |
|---|---|---|
| Runs on | Directly on the hardware | On top of a normal host OS |
| Performance | Higher (no host OS in the way) | Lower (extra OS layer) |
| Typical use | Servers, data centers, cloud | Laptops, desktops, dev/test |
| Examples | VMware ESXi, Microsoft Hyper-V, KVM, Xen | Oracle VirtualBox, VMware Workstation/Fusion |
TYPE 1 (bare-metal) TYPE 2 (hosted)
┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐
│ VM │ │ VM │ │ VM │ │ VM │ │ VM │
└────┘ └────┘ └────┘ └────┘ └────┘
┌──────────────────┐ ┌──────────────┐
│ Hypervisor │ │ Hypervisor │ (an app)
└──────────────────┘ ├──────────────┤
┌──────────────────┐ │ Host OS │
│ Hardware │ ├──────────────┤
└──────────────────┘ │ Hardware │
└──────────────┘
Clouds run Type 1 hypervisors for performance and density. Type 2 is what you'd use on your own laptop to spin up a test VM.
KVM is a hybrid case
KVM turns the Linux kernel itself into a hypervisor, so it has bare-metal performance while looking like part of a normal Linux host. It is the engine behind most OpenStack and many public-cloud deployments.
Anatomy of a virtual machine¶
A VM is a set of virtualized hardware backed by files and host resources:
| Virtual component | What it is | Backed by |
|---|---|---|
| vCPU | Virtual processor cores | Time-sliced shares of physical CPU cores |
| vRAM | Memory presented to the guest | A region of host RAM |
| Virtual disk | The VM's "hard drive" | A file or volume on host/shared storage (.qcow2, .vmdk, .vhdx) |
| Virtual NIC | Network interface | A virtual switch/bridge on the host |
Host vs. guest¶
- The host is the physical machine and its hypervisor.
- A guest is an operating system running inside a VM.
One host runs many guests, each unaware it is virtualized (or only loosely aware, via guest tools/drivers that improve performance).
Lifecycle features that make VMs powerful¶
Because a VM is essentially software and files, the hypervisor can do things that are impossible with physical machines:
- Snapshots — capture the exact state of a VM (disk, and optionally memory) at a moment in time, then roll back to it. Great before risky changes; not a substitute for real backups, as snapshots live on the same storage.
- Templates and cloning — turn a configured VM into a reusable golden image, then stamp out identical copies in seconds. This is how a cloud launches thousands of instances from one image.
- Live migration — move a running VM from one host to another with little or no downtime (e.g. VMware vMotion, KVM live migration). This lets operators patch or retire hardware without taking workloads offline.
Overcommit and resource scheduling¶
Because not every VM uses all its allocated resources at once, hypervisors can overcommit — allocate more virtual resources than physically exist:
- CPU overcommit — many vCPUs share fewer physical cores; the scheduler time-slices them. Fine until everyone wants the CPU at once (contention, "CPU steal").
- Memory overcommit — techniques like ballooning, page sharing, and swap let the sum of vRAM exceed physical RAM. Over-aggressive overcommit causes swapping and steep performance loss.
The hypervisor's scheduler decides which VM gets the physical CPU and when, balancing fairness against priority. Sensible overcommit ratios are how providers get high utilisation; bad ones are how "noisy neighbours" ruin performance.
From virtualization clusters to cloud instances¶
Providers combine these pieces into a cloud:
- Many physical hosts are grouped into clusters with shared storage and a fast network.
- A control plane (orchestrator) tracks free capacity across the cluster.
- When you request an instance, it places a VM on a host with room, boots it from a template/image, attaches block storage and a virtual NIC, and meters your usage.
- Live migration and snapshots let the provider maintain hardware and offer resilience features beneath you.
So an "instance type" with N vCPU and M GB RAM is just a VM definition the orchestrator schedules onto the pool. See What Is Cloud Computing? for the service-model context and Cloud Storage and Networking for the disks and networks attached to it.
A brief contrast with containers¶
Virtualization isn't the only way to isolate workloads.
| Virtual machine | Container | |
|---|---|---|
| Isolates | A full OS, kernel and all | A process, sharing the host kernel |
| Boots in | Seconds to minutes | Milliseconds to seconds |
| Size | GBs (whole OS) | MBs (just the app + deps) |
| Isolation strength | Strong (separate kernels) | Lighter (shared kernel, namespaces/cgroups) |
VMs give stronger isolation and run any OS; containers are lighter and faster but share the host kernel. They are often combined (containers running inside VMs in a cloud). Dive deeper in Containers and Kubernetes.
The open-source path: KVM, libvirt, and Proxmox¶
You can run the same technology the clouds use, for free, on your own hardware — a great home-lab project:
- KVM — the kernel-based hypervisor built into Linux (a Type 1 engine).
- libvirt — a management API and toolkit (
virsh,virt-manager) for defining and controlling KVM/QEMU VMs. - Proxmox VE — a complete open-source platform that wraps KVM (and LXC containers) with a web UI, clustering, snapshots, and live migration — effectively a private virtualization cluster you can build at home.
# Inspect KVM/libvirt VMs on a Linux host
virsh list --all # list all defined VMs
virsh dominfo myvm # vCPU, memory, state of one VM
virsh snapshot-create-as myvm before-upgrade # take a snapshot
This is the same foundation an OpenStack private cloud builds on, and the Linux skills behind it live in the Linux track. You can even manage VM provisioning as code with Terraform.
Verify your work¶
Check your understanding with these conceptual self-tests:
- Can you explain in one sentence why virtualization is the foundation of cloud?
- Given a hypervisor (ESXi, VirtualBox, KVM, Hyper-V), can you classify it as Type 1 or Type 2 and justify it?
- Can you name the four virtual components of a VM and what each maps to on the host?
- Can you explain the difference between a snapshot and a backup, and why a snapshot alone is risky?
- Can you describe what CPU and memory overcommit are, and one symptom of overcommitting too aggressively?
- Can you state two differences between a VM and a container?
Summary¶
Virtualization splits one physical host into many isolated VMs via a hypervisor — Type 1 runs on bare metal (ESXi, Hyper-V, KVM, Xen) and powers clouds, while Type 2 runs on a host OS (VirtualBox, Workstation) for desktops. A VM is virtual hardware — vCPU, vRAM, virtual disk, virtual NIC — backed by host resources and files, with a host running many guests. Snapshots, templates/cloning, and live migration make VMs flexible, while overcommit and scheduling drive utilisation. Providers orchestrate clusters of these into on-demand instances. Containers offer lighter, kernel-sharing isolation as a complement, and KVM/libvirt/Proxmox let you run the whole stack yourself.