Virtualization — type 1 and type 2 hypervisors: Worked examples

The scenario matrix

Think of every problem this topic can throw as living in one of these cells. Each cell is a "sign" or "edge case" — just like a trig problem lives in a particular quadrant.

Cell	Case class	The twist it tests
C1	Pure Type 1 (boots the metal)	No OS underneath — recognise "installed on blank hardware"
C2	Pure Type 2 (app on a host)	An existing OS owns the hardware first
C3	Hybrid / degenerate (KVM)	The host OS becomes the hypervisor — is it 1 or 2?
C4	Zero-guest / limiting case	Hypervisor running but no VM booted yet — overhead = ?
C5	Emulator, NOT a hypervisor	"Virtual" word-trap: full instruction simulation
C6	Nested virtualization	A hypervisor running inside a VM — counting layers
C7	Quantitative overhead	Compute the latency penalty from layer crossings
C8	Real-world word problem	Pick a type from business constraints (cost, security)
C9	Exam-style twist	Popek–Goldberg / non-trapping instruction reasoning
C10	Paravirtualization	Guest modified to call the hypervisor by explicit hypercalls

Below, every cell gets at least one fully worked example.

First, SEE the layer crossings

Almost every example on this page boils down to counting layer crossings, so let's draw them before we count them. In the figure below, follow a single hardware request (the arrows) as it travels downward from a guest to the silicon. Each arrow that steps from one software box to the next is one crossing.

Figure — Virtualization — type 1 and type 2 hypervisors

C1 · Pure Type 1 — boots the bare metal

Worked example Example 1 (cell

C1) Q: An IT team wipes a rack server clean, inserts a USB, and installs VMware ESXi. The machine reboots straight into ESXi's console. They then create 4 VMs. Type 1 or 2, and how many layers separate a guest from the silicon?

Forecast: Type ? , layers = ?

Identify what booted the machine. Why this step? The single discriminator is "what sits directly on the hardware." Here ESXi itself is what powers on — there is no Windows/Linux beneath it. → hypervisor is on the metal (the left stack in the figure above).
Count the layers to silicon. Why this step? Type is decided by layer count. Path is guest OS → ESXi → hardware: one orange arrow, so one software layer (ESXi) between VM and metal.
Conclude. Why this step? We must turn the two facts we just gathered (booted itself + 1 layer) into the actual classification the question asked for. One layer + boots itself ⇒ Type 1.

Verify: Sanity check — could a user "close" ESXi like an app to get a desktop? No; there is no desktop underneath. That absence is the fingerprint of Type 1. ✓ (layer count = 1, checked in VERIFY.)

C2 · Pure Type 2 — an app on a host OS

Worked example Example 2 (cell

C2) Q: On a Windows 11 laptop you launch VirtualBox and boot an Ubuntu guest. Type 1 or 2? Layers to silicon?

Forecast: Type ? , layers = ?

Ask who owns the hardware first. Why this step? Windows booted the laptop and already controls the CPU, RAM and disk. VirtualBox started after, as an icon you double-clicked — an ordinary application. This is the right stack in the figure: a plum host-OS box beneath the hypervisor.
Trace one hardware request from the guest. Why this step? This is how we count crossings. Ubuntu asks for disk → VirtualBox (crossing 1) → Windows (crossing 2) → hardware. Two orange arrows ⇒ two software layers.
Conclude. Why this step? We convert the layer count into the classification the question demands. Two layers + launched like an app ⇒ Type 2.

Verify: Closing VirtualBox returns you to a normal Windows desktop — the host OS was there all along. Layer count = 2. ✓

C3 · Hybrid / degenerate — the KVM trick

Worked example Example 3 (cell

C3) Q: A Linux server loads the KVM kernel module and runs guests via QEMU/KVM. Type 1, Type 2, or something else?

Forecast: Type ?

Locate KVM in the stack. Why this step? KVM is not an app on top of Linux; it is a module inside the Linux kernel. Loading it turns the kernel itself into a hypervisor — so the "host OS" box and the "hypervisor" box of the right stack merge into the single box of the left stack in our figure (a degenerate collapse, as defined above).
Check who has the top privilege level. Why this step? The type is really "does the hypervisor run at the most privileged level directly on hardware?" With KVM, the Linux kernel is that privileged layer — there is no separate host-OS app beneath a hypervisor.
Resolve the degeneracy. Why this step? KVM is a hybrid (one box plays two roles), so we must decide which side of the fence it lands on. Since host OS and hypervisor are the same layer, it behaves like a 1-layer stack ⇒ effectively Type 1 (the classic "hybrid" exam answer).

Verify: Contrast with Example 2 — there VirtualBox was a distinct layer above Windows (2 layers). Here kernel+VMM collapse into 1 layer. The collapse is exactly why we call C3 a degenerate case. ✓ (effective layers = 1.)

C4 · The limiting case — hypervisor with zero guests

Worked example Example 4 (cell

C4) Q: ESXi is running on a server, but no VM has been created yet. What is the guest-to-hardware overhead right now? What happens to the overhead as the number of VMs $n \to 0$ ?

Forecast: overhead = ?

Define overhead as per-guest crossing cost. Why this step? Overhead only exists when a guest issues a request that must cross layers (an orange arrow in the figure). With zero guests, there are zero such requests. Recall $δ$ (defined above) is the cost of one crossing.
Take the limit. Why this step? We want the boundary behaviour — the "what if it shrinks to nothing" edge of the matrix. If each guest pays $δ$ per crossing and $n$ guests generate work, total virtualization penalty scales like $n \cdot δ$ . As $n \to 0$ , $n \cdot δ \to 0$ .
Conclude. Why this step? The limit computed in step 2 must be translated back into the plain-language answer the question asked. With no guests the hypervisor is idle overhead-wise: guest-visible overhead = 0. (The hypervisor still uses some RAM/CPU to exist, but no trap-and-emulate cost is paid.)

Verify: $lim_{n \to 0} n δ = 0$ . Matches intuition: a landlord with no tenants does no room-handing work. ✓

C5 · The word-trap — emulator is NOT a hypervisor

Worked example Example 5 (cell

C5) Q: You run an ARM Raspberry-Pi OS on an x86 laptop using pure QEMU (software emulation, no KVM). Is QEMU here a Type 1 hypervisor, Type 2 hypervisor, or neither?

Forecast: classification = ?

Check whether guest instructions run on the real CPU. Why this step? A hypervisor runs most guest instructions directly on the physical CPU and only traps the privileged ones. Here the guest is ARM but the CPU is x86 — no ARM instruction can run natively.
Name what QEMU is doing. Why this step? Since every instruction is translated in software, QEMU is emulating the whole CPU instruction-by-instruction. That is an emulator, not trap-and-emulate.
Conclude. Why this step? We must answer the classification the question posed. Full software simulation ⇒ neither Type 1 nor Type 2 — it is an emulator. (The same QEMU with KVM and a matching architecture would become a Type-1-style hypervisor.)

Verify: Discriminator table: hypervisor ⇒ same ISA, direct execution + traps; emulator ⇒ cross-ISA, full simulation. Cross-ISA here ⇒ emulator. ✓

C6 · Nested virtualization — counting layers carefully

Worked example Example 6 (cell

C6) Q: A cloud provider runs ESXi on the metal. Inside a VM they run Hyper-V, and inside that they boot a Windows guest. How many software layers now sit between the innermost guest and the silicon?

Forecast: layers = ?

List the stack top-to-bottom. Why this step? Nested cases are only confusing if you don't write the stack down. Take the left stack of the figure and insert a second hypervisor box: hardware → ESXi (L1) → outer VM's OS runs Hyper-V (L2) → innermost Windows guest.
Count crossings from innermost guest. Why this step? The overhead argument still holds; each hypervisor is a crossing. Innermost → Hyper-V (crossing 1) → ESXi (crossing 2) → hardware. Two hypervisor layers.
Conclude. Why this step? We turn the crossing count into the numeric answer the question wanted. 2 layers, and note performance is worse than a single Type 1 because privileged instructions may trap twice.

Verify: Non-nested Type 1 had 1 layer (Ex 1); adding one nested hypervisor gives $1 + 1 = 2$ . ✓

C7 · Quantitative overhead — computing the penalty

Worked example Example 7 (cell

C7, quantitative) Q: A privileged operation costs $t_{h w} = 1.0 μ s$ on raw hardware. Each layer crossing adds $δ = 0.2 μ s$ (the per-crossing cost defined earlier). Compute the total time on Type 1, on Type 2, and the percentage overhead of Type 2 relative to Type 1.

Forecast: T_1 = ? , T_2 = ? , extra % = ?

Type 1 time. Why this step? Type 1 = 1 crossing (the single orange arrow of the left stack), so it pays exactly one $δ$ . In plain words: hardware time plus one crossing toll. $T_{1} = 1.0 + 1 \times 0.2 = 1.2 μ s$ .
Type 2 time. Why this step? Type 2 = 2 crossings (the two orange arrows of the right stack), so it pays two tolls. $T_{2} = 1.0 + 2 \times 0.2 = 1.4 μ s$ .
Percentage overhead. Why this step? "How much slower is Type 2?" is a relative comparison, so we divide the extra time by the Type 1 baseline: $\frac{T _{2} - T _{1}}{T _{1}} = \frac{1.4 - 1.2}{1.2} = \frac{0.2}{1.2} \approx 0.1667 = 16.67%$ .

Verify: Units: $μ s$ throughout — consistent. $T_{2} > T_{1}$ as the theory demands (extra host hop = the extra plum box). $16.67%$ checked in VERIFY. ✓

Worked example Example 8 (cell

C7, general formula + a degenerate delta) Q: Generalise: with $L$ layer crossings, total time is $T (L) = t_{h w} + L δ$ . (a) Write the overhead ratio of Type 2 to Type 1. (b) What happens as $δ \to 0$ (perfect hardware-assisted virtualization)?

Forecast: ratio formula = ? , limit = ?

Ratio. Why this step? Substitute $L = 2$ and $L = 1$ into $T (L)$ so we can compare the two stacks directly: $R = \frac{t _{h w} + 2 δ}{t _{h w} + 1 δ}$ .
Degenerate limit $δ \to 0$ . Why this step? This models VT-x/AMD-V making crossings almost free (the orange arrows cost nothing). Then $R \to \frac{t _{h w}}{t _{h w}} = 1$ .
Interpret. Why this step? A bare number means little until we translate it into a claim about the real world. With near-zero crossing cost, Type 2 is near-native — exactly the "Type 2 is not always slow" point from the parent's mistakes section.

Verify: Plug $t_{h w} = 1, δ = 0.2$ : $R = 1.4/1.2 \approx 1.1667$ (matches the $16.67%$ ). Then $δ = 0 \Rightarrow R = 1$ . ✓

C8 · Real-world word problem — choose the type

Worked example Example 9 (cell

C8) Q: A startup must host 200 production customer servers with maximum security and lowest overhead, on machines they fully control. A separate solo developer needs to quickly test her app on Windows and Linux from her personal laptop. Recommend a hypervisor type for each, with the deciding reason.

Forecast: startup = ? , developer = ?

Startup priorities → performance + small attack surface. Why this step? Match constraints to the comparison table. Lowest overhead ⇒ fewer layers ⇒ the left stack ⇒ Type 1. Smallest security surface ⇒ thin hypervisor, no full host OS ⇒ Type 1. ⇒ Type 1 (e.g. ESXi / KVM).
Developer priorities → convenience on an existing laptop. Why this step? She already runs Windows and can't dedicate the machine (the plum host-OS box is already there). Ease of setup + run-as-app ⇒ Type 2. ⇒ Type 2 (e.g. VirtualBox).
Conclude. Why this step? The question asked for one pick per actor, so we must state both decisions explicitly. Type 1 for the datacenter, Type 2 for the laptop.

Verify: Cross-check against parent table's "Use case" row: Type 1 = data centers/cloud; Type 2 = dev/test/laptops. Matches exactly. ✓ (See also Containers vs Virtual Machines and Cloud Computing for scaling this further.)

C9 · Exam-style twist — Popek–Goldberg reasoning

Worked example Example 10 (cell

C9) Q: An exam states: "On old x86, the instruction POPF is sensitive (it can change the interrupt-enable flag) but does not trap when run in user mode." Using Popek & Goldberg, explain why plain trap-and-emulate fails here, and name one fix.

Forecast: why it fails = ? , a fix = ?

State the condition. Why this step? We need the rule before we can show it is broken. Popek & Goldberg require every sensitive instruction (one that changes or depends on machine state) to be a subset of the privileged (trapping) instructions. Only then can the hypervisor catch every dangerous op.
Show the violation. Why this step? We must locate exactly where POPF breaks the rule. POPF is sensitive but not privileged (it does not trap in user mode). So when the guest runs it, the CPU does not hand control to the hypervisor — the sensitive change happens silently and wrongly. The subset condition is broken, so pure trap-and-emulate cannot intercept it. That is why it fails.
Name a fix. Why this step? The question explicitly asks for a remedy, so we must make the un-trappable op catchable again. Options: binary translation (rewrite the bad instruction on the fly), paravirtualization (modify the guest to call the hypervisor explicitly), or hardware-assisted virtualization (Intel VT-x / AMD-V add a real guest mode so even POPF traps cleanly). Any one is a valid answer; VT-x is the modern default.

Verify: Logical check — "efficient trap-and-emulate ⇔ sensitive ⊆ privileged." Here sensitive ⊄ privileged, so the ⇔ tells us pure trap-and-emulate is impossible. ✓ (See CPU Privilege Rings and System Calls and Traps for the trap machinery.)

C10 · Paravirtualization — the guest asks nicely

Worked example Example 11 (cell

C10) Q: A Xen deployment runs a specially patched Linux guest that never issues raw privileged instructions — it calls HYPERVISOR_* hypercalls instead. (a) Which of the three fixes from Example 10 is this? (b) Does the guest run unmodified? (c) Is this still a Type 1 or Type 2 hypervisor?

Forecast: (a) ? , (b) ? , (c) ?

Match the technique to the fix list. Why this step? Example 10 gave three remedies; we must name which one is in play so we know its trade-offs. The guest is edited to call the hypervisor directly ⇒ this is paravirtualization, not binary translation and not hardware assist.
Decide whether the guest is unmodified. Why this step? The defining property of paravirtualization is a changed guest, and that is the key exam distinction versus VT-x (which runs guests untouched). Since the kernel was patched to issue hypercalls, the guest is modified — you cannot run a stock, unaware OS this way.
Classify the type. Why this step? The question still asks Type 1 vs Type 2, and paravirtualization does not change where the hypervisor sits. Xen boots the metal and sits directly on hardware (left stack), so it is Type 1. Paravirtualization is about the guest–hypervisor interface, an orthogonal axis to the Type 1/2 split.

Verify: Consistency check — paravirtualization changes how crossings happen, not how many layers exist. Xen still has 1 layer to silicon ⇒ Type 1, matching Example 1's layer count. And "modified guest" is precisely the trait absent from VT-x. ✓

One decision tree that replays every example

Now that you have worked all cells, here is the single flowchart your brain should run on any new scenario. Walk it once with Example 2 in hand: "What boots the metal?" → a normal OS (Windows) → Type 2. Now walk it with Example 1: → the hypervisor (ESXi) → Type 1. Example 3 (KVM): → a kernel module → Hybrid. And the second branch catches Example 5: the ARM-on-x86 guest fails "same ISA + direct execution", so it drops out as an emulator, never a hypervisor.

Matrix coverage check

Recall Did we hit every cell?

C1 → Ex 1 · C2 → Ex 2 · C3 → Ex 3 · C4 → Ex 4 · C5 → Ex 5 · C6 → Ex 6 · C7 → Ex 7 & 8 · C8 → Ex 9 · C9 → Ex 10 · C10 → Ex 11. Every cell covered. ✓

Active recall

Which cell does "ESXi on a blank server" belong to, and what type?

Cell C1 — Type 1 (boots the metal, 1 layer).

VirtualBox on Windows: type and layer count?

Type 2, 2 layers (guest → VirtualBox → Windows → hardware).

Why is KVM effectively Type 1?

The kernel module makes the Linux kernel itself the hypervisor — host OS and VMM are the same privileged layer (a hybrid/degenerate collapse).

With

t_{h w} = 1 μ s

and

δ = 0.2 μ s

, how much slower is Type 2 than Type 1?

\frac{0.2}{1.2} \approx 16.67%

Cross-ISA QEMU (ARM guest on x86): hypervisor or emulator?

Emulator — no guest instruction runs natively, so it simulates the whole CPU.

As crossing cost

δ \to 0

, the Type-2/Type-1 ratio approaches?

1 (near-native), which is why hardware-assisted Type 2 isn't "always slow".

What is paravirtualization, and does it change the Type 1/2 classification?

The guest is modified to call the hypervisor via explicit hypercalls; it changes the guest–hypervisor interface, NOT where the hypervisor sits, so it does not change Type 1 vs 2.