One more turn of a screw you already know
You have spent this whole course watching one idea repeat: take a real, scarce, awkward resource and hand each user a clean private illusion of it. The kernel gives every process a virtual address space so it believes it owns all of memory; it gives every thread a slice of the CPU through a context switch so each believes it runs alone. Machine virtualization is the same screw turned one full thread further. Instead of fooling a process into thinking it owns the machine, we fool an entire operating system into thinking it owns the bare hardware — its own CPU, its own RAM, its own disks — when in truth it is just one tenant sharing a real computer with several other operating systems.
The software that runs this larger illusion is the hypervisor, also called the virtual machine monitor or VMM — two names for the same thing, the second older and more precise. Each fooled operating system, with its own kernel and its own programs, is a guest running inside a virtual machine (VM). The hardware and software actually doing the fooling is the host. So this rung adds exactly one new layer beneath the kernel you have studied all along: where you used to think of hardware → kernel → processes, you now think of hardware → hypervisor → (guest kernel → guest processes), several guests side by side. Hold onto that picture; every guide in this rung is a detail of how that one new layer pulls off its trick.
Why is this even hard? Two kernels both want ring 0
Here is the knot at the heart of the problem. Recall from the OS rung that hardware enforces privilege rings: ordinary code runs in unprivileged user mode (ring 3 on x86), and only the kernel runs in the most privileged ring 0, where it may touch page tables, mask interrupts, and run the dangerous instructions that control the machine. That model assumed one kernel per machine. But a guest is a full operating system: its kernel was written expecting to own ring 0. Now we have two kernels — the guest's and the host's hypervisor — and the hardware only has one ring 0. They cannot both sit in it, because then the guest could reach past the curtain and seize the real machine, and the whole illusion collapses.
So the hypervisor must keep ring 0 for itself and demote the guest kernel to a lesser privilege. The guest kernel, not knowing it has been demoted, keeps trying to run privileged instructions exactly as it always did — "disable interrupts," "load this page-table base" — as if it still owned the machine. The classic answer is trap-and-emulate: when the demoted guest attempts a privileged instruction, the hardware refuses and traps — the same trap mechanism behind a system call, a control transfer that jumps into the more-privileged hypervisor. The hypervisor then looks at what the guest was trying to do, performs the effect it intended on a safe private copy of the machine state, and returns control as if nothing unusual happened. The guest never learns it did not touch the real hardware. The full mechanics of trap-and-emulate are the next guide; here we just need that it exists, and the one law that says when it is enough.
Two places a hypervisor can live: type-1 and type-2
Now the practical fork. A hypervisor needs ring 0, but what sits between it and the bare metal admits two designs, and the type-1 vs type-2 distinction is simply which one you chose. A type-1 (or "bare-metal") hypervisor is the thing on the metal: it boots first, owns ring 0 from the start, and is itself a small specialized kernel whose only job is hosting guests. There is no general-purpose OS underneath it. Think of products like Xen, VMware ESXi, or Microsoft Hyper-V — the kind of thing a cloud provider runs on a server, where every operating system on the box is a guest and there is no "normal" OS you log into.
A type-2 (or "hosted") hypervisor is the opposite arrangement: a normal operating system — Linux, macOS, Windows — boots first and owns the metal as usual, and the hypervisor runs as a program on top of that host OS, using the host kernel for the heavy lifting of disks, networking, and scheduling. Think of VirtualBox or VMware Workstation: an app you launch on your laptop that opens a window with another whole OS running inside. The cleanest modern example is Linux's KVM, which turns the ordinary Linux kernel itself into a hypervisor through a driver, so the same machine is your everyday desktop and a VM host at once. The line between the categories can blur — KVM is often called type-1-ish because the hypervisor logic lives inside the host kernel — but the question that defines the split is sharp: does the hypervisor boot on bare metal (type-1), or does it run atop a pre-existing general OS (type-2)?
TYPE-1 (bare-metal) TYPE-2 (hosted)
---------------------- ----------------------
[ guest OS ] [ guest OS ] [ guest OS ] [ apps ]
-------------------------- ----------------+-----
| hypervisor | | hypervisor (a program) |
| (small kernel, ring 0) | --------------------------
-------------------------- | host OS kernel |
| bare hardware | --------------------------
-------------------------- | bare hardware |
--------------------------What the VMM must fake, organ by organ
It helps to be concrete about what the monitor must counterfeit, because a real computer is not one resource but several, and the guest expects all of them. There are three big organs. First the CPU: the guest must seem to run its own instructions at full speed on its own processor, including the privileged ones we saw it cannot really execute — that is the trap-and-emulate problem, and on its own it is too slow until hardware helps. Second memory: the guest kernel builds its own page tables believing its "physical" addresses are real RAM, but they are not — they are themselves virtual, and a second translation must map the guest's idea of physical memory onto the host's actual physical RAM. Third devices: disks, network cards, timers — the guest expects to talk to hardware that, for it, does not physically exist.
Each organ is one upcoming guide, so let this be your map of the rung. For the CPU, raw trap-and-emulate is too costly, so chip makers added hardware-assisted virtualization — Intel's VT-x, AMD's AMD-V — which gives the CPU a distinct guest mode so the guest kernel can run in something that looks like ring 0 without owning the real one, dropping into the hypervisor only on a special VM exit; that is guide 2. For memory, the second translation is done either by software shadow page tables or by hardware nested paging (Intel EPT, AMD NPT); that is guide 3. For devices, rather than emulate a real card bit-for-bit, the guest and host can agree on a fast cooperative interface — paravirtualization and the virtio standard — which is guide 4. And guide 5 steps sideways to a lighter-weight cousin, containers, where the guest does not get its own kernel at all.
Honest limits, and why anyone bothers
Now the honest part, because virtualization is genuinely powerful but it is not free, and pretending otherwise breeds bad intuition. Every trap into the hypervisor costs real time — a control transfer, saved and restored state, the monitor's own work — so a workload that does little but bang on privileged instructions or hardware can run noticeably slower in a VM than on bare metal. The whole arc of this rung is a chase to make that overhead small: hardware guest modes to avoid traps, nested paging to avoid software page-walking, paravirtual devices to avoid faithfully emulating chips. With those, a well-behaved guest runs at near native speed for ordinary work — but "near," not "equal," and the gap widens exactly for the privileged, I/O-heavy, or interrupt-heavy code that has to keep crossing into the monitor.
So why pay anything at all? Because the illusion buys you things the bare machine cannot. Isolation: a guest that crashes, or is broken into, is sealed inside its VM and cannot reach the host or its neighbors — far stronger than the process boundary, because even the guest's kernel is contained. Consolidation: one big physical server can host many guests at once, each thinking it has a whole computer, so idle capacity is shared instead of wasted — the economic engine under all cloud computing. Flexibility: because a VM is just state the hypervisor manages, you can snapshot it, clone it, or even move a running guest to another physical host with barely a hiccup. None of that is possible if an OS is welded to one piece of metal. That is the bargain of this whole rung: a measured, shrinking performance cost in exchange for isolation, consolidation, and a machine you can pick up and move.