2.1 Virtualization — the thing the cloud is built on

Describes the cloud compute landscape as of August 2026

What this is and why it exists

Every rented machine you will ever start is a lie the hardware agrees to tell. Virtualization is what turns one physical server into forty that each believe they are alone, and it is the mechanism underneath renting-by-the-second, elasticity, and most of the surprises in your bill. Understand it once and half the cloud stops being magic.

The vocabulary

  • Hypervisor — the layer that shares one physical machine between several virtual ones and keeps them apart.
  • Type 1 (bare metal) — a hypervisor running directly on the hardware, with no operating system beneath it; what every cloud provider runs.
  • Type 2 (hosted) — a hypervisor running as an application inside an ordinary operating system; what you run on your laptop.
  • Guest — one virtual machine; host is the physical machine carrying it.
  • Full virtualization — the guest is unmodified and believes it owns real hardware.
  • Para-virtualization — the guest knows it is virtual and cooperates, trading transparency for speed.
  • Hardware-assisted virtualization — processor features that make the trap-and-emulate work cheap; the reason modern virtual machines are near-native speed.
  • Live migration — moving a running guest to another host without it stopping.
  • Noisy neighbour — another guest on your host consuming a shared resource you also need.

The mental model

A hypervisor is an operating system whose processes happen to be whole computers. It does what any scheduler does — hands out slices of processor, memory, disk and network — but its tenants each run their own kernel and believe the slices are the whole machine.

The three flavours are three answers to one question: what happens when the guest tries a privileged instruction the hypervisor must not let through? Full virtualization intercepts and emulates it, so the guest needs no changes and pays a cost. Para-virtualization changes the guest to ask politely instead, which is faster but only works on a guest you can modify. Hardware-assisted virtualization moves the interception into the processor itself, which is why the question is largely historical now — you get near-native speed with an unmodified guest. Cloud providers use hardware assistance and increasingly offload the network and storage work to dedicated cards; the providers' own names for this differ, and your topic's provider map records that Amazon calls its arrangement the Nitro hypervisor, Azure builds on Hyper-V, and Google builds on KVM.

The lifecycle is worth holding as a single picture, because your later bills are made of it: provision from an image, snapshot for a point you can return to, migrate when the host must be patched, suspend when you want the state but not the cost, destroy when you are done. Live migration is the hard one — the guest keeps running while its memory is copied to another host, then a very short pause switches it over. Its difficulty is the reason a provider will occasionally tell you a machine must be stopped, and the reason those maintenance events exist at all.

Containers answer the same problem one level up. Instead of many kernels on one hypervisor, containers share the host's single kernel and separate what processes can see. That makes them start in milliseconds rather than tens of seconds, and much smaller to ship — at the price of weaker isolation, because a shared kernel is a shared blast radius, and no choice of guest operating system.

Storage and network are virtualized by the same logic: a virtual disk is a file or a remote volume the guest sees as a disk, and a virtual network card carries traffic the host actually routes. Which is exactly where noisy neighbours come from — the sharing is real even when the isolation is convincing. Your guest's disk latency can rise because someone else's guest is busy, and no amount of looking inside your own machine will explain it.

What you should now be able to explain or do

Explain to a non-technical friend how one server becomes forty. Say which hypervisor type a cloud provider uses and why. Give the difference between full and para-virtualization in one sentence each, and say what hardware assistance changed. Name the five stages of a machine's life and say which one live migration protects. State two things containers gain over virtual machines and two things they give up. Describe a noisy-neighbour symptom and why your own metrics will not explain it.

Check yourself

Type 1 runs directly on the hardware with no operating system underneath; type 2 runs as an application inside one. Providers run type 1, because a whole extra operating system between the hardware and the guests would be pure overhead.

It moved the interception of privileged instructions into the processor, so an unmodified guest runs at near-native speed. That largely removed the reason to modify guests for para-virtualization.

The guest must keep running while its memory is copied to another host, with only a very brief switchover. It buys the ability to patch and retire hardware without stopping customers' machines.

Containers share the host kernel instead of each running their own, so there is far less to start — and correspondingly less isolation, plus no choice of a different guest operating system.

A noisy neighbour — another guest on the same host consuming shared storage or network capacity. The isolation is about what others can see, not about what they can consume.

Go deeper

Back to Virtualization — the thing the cloud is built on: work through the checklist