Virtualisierung & Sandboxing: VMMs, CPU, Memory, I/O, Container

Virtualisierung & Sandboxing

Lecture 3 of Cloud, Web & Mobile (Univ. Duisburg-Essen, Torben Weis), 42 slides, deck of 02.10.2026. Four blocks:

1. Hardware-Virtualisierung — why, and what a VM monitor must do
2. CPU-Virtualisierung — rings, deprivileging, the IA-32 holes, VT-x
3. Hauptspeicher- und I/O-Virtualisierung — shadow page tables, device models
4. Sandboxing (Container) — Docker, namespaces, cgroup v2

Source status: PARTIAL. The PDF is Firefox-printed (2.7 MB, 42 p.) and 19 of its slides are figure-only — the text extractor returns just the header line for them. All diagrams below were reconstructed from the rendered pages, so nothing is missing; but a re-run of pdf2md will always look “thin” on this file. Recorded in the course Materials table.

1. Why virtualize: three use cases

The lecture opens with three pictures, each a before → after. They are the entire motivation, and each maps to a different business driver.

Workload Isolation — apps on one box, but separated

Left: App1 and App2 share one Betriebssystem on one hardware. Right: each app gets its own guest OS, both running on a VM Monitor (VMM) above the hardware.

flowchart TB
    subgraph before["before: shared OS"]
        direction TB
        b1["App1    App2"] --> b2["Betriebssystem"]
        b2 --> b3["Hardware"]
    end
    subgraph after["after: one VM per app"]
        direction TB
        a11["App1"] --> a12["Betriebssystem"]
        a21["App2"] --> a22["Betriebssystem"]
        a12 --> a3["VM Monitor (VMM)"]
        a22 --> a3
        a3 --> a4["Hardware"]
    end

Driver: security/blast radius — a bug or exploit in App1 no longer reaches App2’s OS.

Workload Aggregation — many boxes into one

Left: two separate machines, each with its own App + OS + Hardware. Right: both OS instances consolidated onto one hardware under a VMM.

flowchart TB
    subgraph before["before: 2 machines"]
        direction LR
        p1["App1 → OS → Hardware"] ~~~ p2["App2 → OS → Hardware"]
    end
    subgraph after["after: 1 machine, 2 VMs"]
        direction TB
        q1["App1 → OS"] --> q3["VM Monitor (VMM)"]
        q2["App2 → OS"] --> q3
        q3 --> q4["Hardware"]
    end

Driver: consolidation/utilisation — servers typically idle; packing them raises utilisation and cuts power/cooling (the lecture’s datacenter block, data-centers-and-iaas, is the same argument one level up).

Workload Migration — move running workloads

The VMM moves with the VM: App + OS + VMM leave hardware A and continue on hardware B.

flowchart LR
    subgraph hwA["Hardware A"]
        direction TB
        m1["App1 → OS"] --> m2["VMM"] --> m3["Hardware"]
    end
    subgraph hwB["Hardware B"]
        direction TB
        n1["App1 → OS"] --> n2["VMM"] --> n3["Hardware"]
    end
    m2 -.->|"live migration"| n2

Driver: maintenance and load balancing — evacuate a host for repair, or move VMs off a hot machine, without stopping the workload. (This is what “live migration” and the cloud’s freedom-to-relocate in the IaaS model rest on.)

Note the pattern in all three: the layer that is added is always the VMM, and the layer it saves you from duplicating is the hardware, never the OS.

2. Four words that the lecture pins down first

“Begriffe: Real, Transparent, Virtuell, Weg” — the four cases of the existence/visibility matrix:

	visible	not visible
exists	real — it is there and you can see it	transparent — it is there, you just cannot see it
does not exist	virtuell — it is not there, but you can see it	weg (“gone”) — not there, and not visible

That “virtuell” cell is the whole trick: a guest OS sees a disk, a NIC, a CPU with N cores — none of which exist as such. And the “transparent” cell is where the VMM itself lives: the guest must not notice it.

3. The layered model

flowchart TB
    subgraph vm0["VM₀"]
        direction TB
        a0["App   App"] --> o0["OS₁"]
        o0 --> vh0["virtualized hardware of VM₀"]
    end
    subgraph vm1["VM₁"]
        direction TB
        a1["App   App"] --> o1["OS₂"]
        o1 --> vh1["virtualized hardware of VM₁"]
    end
    vh0 --> vmm["VM Monitor (VMM)"]
    vh1 --> vmm
    vmm --> phw["Physical HW resources: CPU, memory, disk, NIC, display, input"]

Layers, top to bottom: Guest OSes (each with its apps) → virtualized hardware of the VM → VMM → physical hardware. The VMM is the only component that talks to real hardware; everything above it sees an invention.

Because the guest’s drivers target virtual devices, the VMM can present a device that does not exist on the host at all — this is why the summary can claim that VMs even make wrong drivers usable (emulation).

4. What a VMM must do — and the only three ways to do it

Anforderungen an den VMM (slide 7):

1. protect itself from the guest operating systems;
2. isolate the guest software (OS + apps) from each other;
3. provide a virtual platform for the guests, i.e. control access to CPUs, memory, I/O devices;
4. share resources among the VMs, via
   • time multiplexing,
   • resource partitioning,
   • mediating hardware interfaces.

The three sharing mechanisms are drawn as three separate pictures — worth memorising as a triplet, because every virtualisation technique in the rest of the lecture is one of them:

mechanism	picture	applies to	cost
Time-Multiplexing	VM₀ and VM₁ alternate on the same processor, the VMM switching back and forth (red double arrows)	CPU, network, disk bandwidth	context-switch overhead; needs a scheduler in the VMM
Resource Partitioning	storage/memory/display are statically sliced, colour-coded per VM (VM₀ blue, VM₁ yellow), through a Remap / Protection Mechanism in the VMM	memory, storage, GPU/display	fixed, so idle shares are wasted; needs address remapping + protection checks
Hardware Mediation	each VM gets its own pair of device models in the VMM (blue/yellow halves), which drive the one real NIC / keyboard / mouse	I/O devices, interrupts	every access traps into the VMM; needs device emulation

Vollständige Hardware-Virtualisierung (“complete hardware virtualisation”) is the picture where all six resource kinds — processor, storage, network, memory, keyboard/mouse, display — are partitioned among VM₀…VM₃ through one VMM. That is what “full” means: no resource class is passed through raw.

Exam-style question that this section answers: “Which mechanisms can a VMM use to share resources, and for which resource would you pick which?” — CPU → time multiplexing; memory → partitioning + remap/protection; I/O → mediation (emulation), optionally accelerated by partitioning (SR-IOV/passthrough).

5. VMM-Architektur: hypervisor vs. hosted

Two architectures, and the difference is exactly where the device drivers live:

flowchart TB
    subgraph t1["Hypervisor Architecture (Type 1)"]
        direction TB
        h0["VM₀: Guest OS + Apps"]
        h1["VM₁: Guest OS + Apps"]
        hn["VMₙ: Guest OS + Apps"]
        hyp["Hypervisor<br/>Device Models (top)<br/>Device Drivers (bottom)"]
        hhw["Host HW"]
        h0 --> hyp
        h1 --> hyp
        hn --> hyp
        hyp --> hhw
    end
    subgraph t2["Hosted Architecture (Type 2)"]
        direction TB
        ua["User Apps"] --> uvmm["User-level VMM<br/>+ Device Models"]
        gn["VMₙ: Guest OS + Apps"]
        g0["VM₀: Guest OS + Apps"]
        hos["Host OS<br/>Device Drivers<br/>+ Ring-0 VMM 'Kernel'"]
        hhw2["Host HW"]
        uvmm --> hos
        gn --> hos
        g0 --> hos
        hos --> hhw2
    end

	Hypervisor (Type 1)	Hosted (Type 2)
drivers in	the hypervisor itself (device models on top, drivers underneath)	the host OS; the VMM is a user-level process plus a small ring-0 kernel module
VMM is	the OS of the machine	an application on top of an existing OS
examples	VMware ESXi, Xen, Hyper-V	VirtualBox, VMware Workstation, KVM+QEMU as a Linux process
advantage	less code in the TCB, better isolation, lower overhead	installs like an app, reuses the host’s huge driver base

The arrows on the slide are the point: in the hosted case the guest’s I/O path loops through the host OS’s driver stack, so the host OS is part of the trusted computing base — and the reason hosted VMMs are convenient but weaker.

6. CPU-Virtualisierung

6.1 Rings, as the hardware offers them

Intel CPUs support 4 rings: ring 0 = OS kernel, rings 1–2 = drivers, ring 3 = applications. But with paging enabled, real CPUs in practice distinguish only ring 0 and ring 3 — and current OSes use a flat memory model (paging only, no segmentation), which is why rings 1 and 2 are unused in practice.

6.2 The naive idea: ring deprivileging

Put the VMM in ring 0 and push the guest OS into ring 1 — the guest becomes “de-privileged” (entrechtet). Two goals: jail the guest OS, and protect the VMM from deliberate attacks as well as from plain programming errors in the guest.

flowchart TB
    subgraph plain["Without Ring Deprivileging"]
        direction TB
        p3["Applications — Ring 3"] --> p0["OS Kernel — Ring 0"]
    end
    subgraph m013["With Ring Deprivileging: the 0/1/3 model"]
        direction TB
        q3["Guest Apps — Ring 3"] --> q1["Guest OS — Ring 1"]
        q1 --> q0["VMM — Ring 0"]
    end
    subgraph m03["With Ring Deprivileging: the 0/3 model"]
        direction TB
        r3["Guest Apps — Ring 3"] --> r3b["Guest OS — Ring 3"]
        r3b --> r0["VMM — Ring 0"]
    end

Two variants are named on the slide: the “0/1/3” model (guest OS in ring 1) and the “0/3” model (guest OS demoted into ring 3, i.e. guest kernel and guest apps share one ring).

6.3 The IA-32 holes

Ring deprivileging fails because IA-32 was never designed to be virtualised — the VMM must handle cases where a privileged instruction behaves differently without trapping, which breaks the “trap every sensitive instruction” assumption. The slide’s six cases, with the instructions it names:

Hole (slide label)	Instructions	Why it hurts
”Expose that guest OS is running in ring 1” (ring aliasing)	PUSH CS/SS, CALL	the current privilege level is pushed onto the stack, so the guest sees it is not in ring 0 — and can adapt/exploit
”Incorporate current ring # in computation” (ring compression)	LAR, LSL, VERR, VERW	with only 2 rings left, ring 0 and ring 3 collapse: those instructions must treat “ring 1” as “kernel”, which the VMM cannot emulate faithfully
”Unable to access hidden segment-register state” (address-space compression)	hidden part of segment registers	on a VM context switch the VMM cannot save/restore the invisible part of the segment state that the guest OS believes it owns
”Non-trapping writes of privileged state”	POPF, CLI, STI, SYSENTER/SYSCALL	the write just silently does nothing (or faults late) instead of trapping — the VMM never learns about it
”Non-trapping reads of privileged state”	CPUID, SGDT, SIDT, SLDT, STR	the guest reads real hardware state (e.g. CPUID features, descriptor table addresses) and the VMM cannot intercept the read
”Excessive Faulting”	the trapped subset of the above	each intercepted operation costs a fault into the VMM; with sensitive instructions everywhere (e.g. CLI/STI in every critical section) performance collapses

The general lesson: virtualisability requires that every sensitive instruction traps (Popek & Goldberg’s criterion), and IA-32 violates it.

6.4 Stopfen der Löcher — three fixes

1. Paravirtualisierung — modify the guest OS so it never falls into a hole. Example: Xen. Benefit: no traps, better performance. Cost: you need the guest source, and the guest must cooperate (so no unmodified Windows/legacy guests).
2. Umschreiben des Binärcodes (binary rewriting) — analyse the guest machine code before execution and rewrite the “dangerous” sites into VMM calls. Problems named on the slide: difficult and not very fast, and it breaks on self-modifying code / JIT techniques.
3. Modifikation der Prozessor ISA — extend the instruction set so virtualisation becomes possible. Example: Intel VT-x.

6.5 VT-x

Starting point: no segments, only paging → only 2 rings → interesting. VT-x adds two CPU modes:

• Root Operation — full privileges for the VMM
• Non-Root Operation — restricted rights for the guest OS

Switching happens with VMXON (enter root operation) and VMXOFF (leave it). The slide’s summary line: “im Wesentlichen eine Spaltung von Ring 0” — essentially a split of ring 0.

flowchart LR
    std1["'Standard' IA-32"] -->|VMXON| root["Root Operation:<br/>VMM"]
    root --> nr["Non-Root Operation:<br/>Ring 3 Apps / Ring 0 OS"]
    root -->|VMXOFF| std2["'Standard' IA-32"]

The decisive gain, marked in red on the slide: “Guest software runs at intended privilege level (no ring deprivileging)” — the guest still thinks it is in ring 0, while the hardware (not the VMM) enforces the boundary, and the tricky cases above become hardware-handled VM exits instead of holes.

7. Hauptspeicher-Virtualisierung

7.1 The problem: memory is already virtualised

Every application sees a linear address space, translated by a page table (CR3 → PD → PT → frame); the OS rewrites that page table. With VMs there are now several page tables — one per guest OS — and the CPU can only use one. Hence doppelte Virtualisierung: the already-virtualised guest memory must itself be virtualised.

The picture: VM₀ and VM₁ each have their own CR3 → PD → PT → pages structure, both feeding a Memory Virtualization layer in the VMM, which maps them onto the real TLB and the real memory (colour-coded frames per VM).

7.2 Two solutions

	Lösung 1: trap every access to the page table	Lösung 2: shadow page table
idea	guest writes to its page table → VMM trap, VMM rewrites the entry after translation; guest reads → trap, VMM serves what the guest thinks it wrote	VMM keeps one page table (its own) and makes the CPU use it; the guest’s table is never used by hardware
CPU uses	guest page table (but must be kept consistent by repeated trapping)	only the VMM’s page table — “the CPU ignores the guest’s table completely”
when the guest writes its table	every write traps and is emulated (very expensive)	VMM adjusts its shadow table in the background
name on the slide	”Abfangen aller Zugriffe"	"Schatten-Tabelle”

Two costs the lecture emphasises for solution 1: every page-table access traps (write and read), and the VMM must emulate table reads (CR3, PD, PT reads) because the guest’s expectations must be preserved.

7.3 The shadow table (VTLB)

flowchart TB
    subgraph vm["VM"]
        direction TB
        g["Guest Page Table<br/>CR3 → PD → PT → guest frames"]
    end
    subgraph vmm["VMM"]
        direction TB
        subgraph vtlb["VTLB"]
            tlb["TLB"]
            act["Active Page Table<br/>CR3 → PD → PT → real frames"]
        end
    end
    g -.->|"VMM mirrors/translates entries:<br/>write-protect guest tables → trap → update"| act
    tlb -->|fast path| act

Reading of the slide’s picture: the guest OS happily maintains its Guest Page Table (its PD/PT nodes refer to guest-physical frames), while the VMM’s VTLB holds the Active Page Table whose PT entries point at real frames. The dashed arrow is the VMM’s job: mirror the guest’s intent into the active table (write-protect the guest’s pages so any guest change traps and can be re-mirrored).

Hardware support later removed this work (Intel EPT / AMD NPT: a second level of page walk in hardware) — the lecture does not cover it, but it is the reason the shadow table is history on modern CPUs.

8. I/O-Virtualisierung

8.1 Where the device code sits

Slide 27 repeats the two architectures and circles the Device Models (top) / Device Drivers (bottom) pair — in the hypervisor for Type 1, in the user-level VMM + host OS for Type 2. Two sentences on that slide are the definition:

• “Virtual device model presents [an] interface to [the] guest operating system”
• “Physical device driver programs and responds to actual device hardware”

So a guest’s e1000-looking NIC is a model, and only the layer below it touches the real NIC. (Which is also why the earlier claim holds: a VM can expose a device with a “wrong” driver, because the model can lie.)

8.2 The full path of one I/O access (slide 28)

flowchart TB
    go["VM₀: Guest OS + Apps"] -->|"① device configuration, I/O-port, MMIO accesses"| vdm["Virtual Device Interface and Model"]
    vdm -->|"② proxy: translate commands,<br/>translate DMA addresses"| pdi["Physical Device Interface and Driver"]
    pdi -->|"③ device configuration, I/O-port &amp; MMIO"| dev["Physical Device"]
    dev -->|"④ DMA to host physical memory,<br/>physical interrupts"| pdi
    pdi -->|"⑤ proxy back: copy/translate DMA buffers,<br/>inject 'virtual interrupts'"| vdm
    vdm -->|"⑥ virtuelle Interrupts"| go

The six annotations of that slide, verbatim in spirit:

1. the guest device driver programs the virtual device interface: device configuration accesses, I/O-port accesses, memory-mapped device registers;
2. the model proxies these to the physical driver: possible translation of commands, translation of DMA addresses;
3. the physical driver programs the actual device: device configuration, I/O-port and MMIO accesses;
4. the device responds: DMA transactions to host physical memory, physical interrupts;
5. the model proxies activity back: copying (or translation) of DMA buffers, injection of “virtual interrupts”;
6. the guest OS receives an interrupt that looks real.

Two costs are inherent: every I/O operation takes an extra hop through the VMM, and DMA buffers must be copied or translated — the memory-virtualisation problem reappearing in the I/O path (a device writing to “guest address 0x1000” must land in the right physical frame).

9. Sandboxing (Container)

9.1 The idea

Starke Isolation ist nicht immer nötig — aber teuer: full VMs need their own page tables, their own kernel, and pay for the hypervisor on every trap. Sandboxing: stop virtualising the OS; run applications directly on the host OS and merely limit what they are allowed to do — a “Sandkasten” with a fence, not a separate house. Examples on the slide: LXC, Docker, Kubernetes.

9.2 Containers vs. VMs

flowchart TB
    subgraph vms["Virtual machines"]
        direction LR
        v1["App A → Bins/Libs → Guest OS"]
        v2["App B → Bins/Libs → Guest OS"]
        v3["App C → Bins/Libs → Guest OS"]
    end
    subgraph cts["Containers"]
        direction LR
        c1["App A → Bins/Libs"]
        c2["App B → Bins/Libs"]
        c3["App C → Bins/Libs"]
    end
    vms --> hyp["Hypervisor"]
    hyp --> infra1["Infrastructure"]
    cts --> ce["Container Engine"]
    ce --> hos["Host Operating System"]
    hos --> infra2["Infrastructure"]

(Image in the deck is from Atlassian, containers vs. VMs — the standard picture: the VMs each carry a full Guest OS, the containers share one Host OS through a Container Engine.)

9.3 Vor- und Nachteile (slide 32)

Vorteile	Nachteile
keine zusätzlichen Seitentabellen — no second-level paging, no shadow tables	schwächere Isolation — one kernel for everyone
keine Löcher in der Ausführung — no ring deprivileging, no VM exits	Fehler im Kernel/Engine geben direkt mehr Zugriff — a kernel or runtime escape compromises the whole host
schneller (Start und Ausführung), annähernd native Geschwindigkeit	no different guest OS / kernel version per container

That trade-off is the exam’s likely single sentence: containers trade isolation for speed and density.

10. Docker: namespaces und cgroups

10.1 Was Docker ist

• das bekannteste Container-Engine-Projekt;
• riesiges Ökosystem vorbereiteter Images;
• läuft auf Windows/macOS/Linux — aber Container sind fast ausschließlich Linux;
• mehrere Engines lassen sich vernetzen (Docker Swarm).

Mechanically, Docker builds sandboxes out of two Linux features: namespaces (what a process can see) and cgroup v2 (how much a process may use).

flowchart LR
    img["Image<br/>(filesystem layers)"] --> ctr["Container = process(es)"]
    ns["namespaces<br/>visibility"] --> ctr
    cg["cgroup v2<br/>resources"] --> ctr
    ctr --> kernel["one shared Linux kernel"]

10.2 namespaces — isolation of visibility

Laufende Prozesse werden anhand ihrer Prozess-ID (PID) in Baumstrukturen einsortiert; ein namespace versteckt alles außerhalb seiner selbst. Prozesse in verschiedenen namespaces sehen jeweils andere Netzwerkadapter, andere PIDs, andere User.

• 8 Arten von namespaces (seit Linux 5.6): mnt, pid, net, ipc, uts, user, cgroup, time (the slide names User, PID, Time, Network, IPC…);
• Folgen, die das Konzept erst interessant machen:
  • PID 1 kann mehrfach vorkommen,
  • User 1 kann bei zwei Prozessen verschieden sein,
  • namespaces können von höheren Prozessen dynamisch zugewiesen werden,
  • Kinderprozesse übernehmen die namespaces ihrer Eltern.

The slide’s worked example (PID namespaces) — one process tree, three views:

flowchart TB
    init["PID 1 · ns 1<br/>init"]
    init --> bash["PID 2 · ns 2<br/>bash"]
    bash --> sleep["PID 3 · ns 2<br/>sleep 30"]
    init --> term["PID 4 · ns 3<br/>terminal"]
    term --> mutt["PID 5 · ns 3<br/>mutt"]

real view (init, ns 1)	view of bash (ns 2)	view of mutt (ns 3)
PID 1 → init	PID 1 → bash	PID 1 → terminal
PID 2 → bash	PID 2 → sleep 30	PID 2 → mutt
PID 3 → sleep 30
PID 4 → terminal
PID 5 → mutt

The same kernel processes have different PIDs in different namespaces — the essence of “the container thinks it is PID 1 on a private machine”.

10.3 cgroup v2 — isolation of resources

• also a tree structure; cgroup v1 had several trees and was very complex, cgroup v2 (Linux 4.5+) has one tree;
• two components: the tree/grouping of processes, and the controllers that assign resources to groups;
• plus a cgroup namespace to hide the tree itself.

Ziele der cgroups (slide 38): Ressourcenlimitierung, Priorisierung, Accounting, Kontrolle — with the slide’s examples:

• halt group 6 when its processes have run for 10 s,
• processes in group 3 may use at most 1 GB RAM,
• if group 1 wants to compute, group 2 has to wait.

Controller (slide 39): one per resource kind — cpu, cpuset, freezer, io, memory, pid, …

Modus	Bedeutung
Weight	Gewichte verteilen → aufsummieren → anteiliger Zugriff
Limits	maximale Menge N pro Gruppe — die Summe darf die echte Hardware übersteigen (Overcommit)
Protections	Gruppe bekommt mindestens N
Allocations	fixe Zuweisung, z. B. Realtime-Budget der CPU

The overview picture (slide 40) connects it end to end: the Resources (6 CPUs, RAM) are sliced between two cgroups — g1-web (red: CPUs 1, 3, 5 + some RAM pages) running three /usr/sbin/httpd processes, and g2-db (blue: CPUs 0, 2, 4 + other RAM pages) running four /usr/sbin/postgres processes. Same kernel, same RAM stick, disjoint resource slices, disjoint process views.

10.4 The rest of Docker (slide 41)

Dateisystemfeatures (Layering of images, Volumes), virtuelle Netzwerkinterfaces, iptables/nftables for port mapping and isolation, verteilte Runtimes (Docker Swarm, Kubernetes) — the lecture stops here and points at https://docs.docker.com/.

11. Zusammenfassung (slide 42)

VMs

• stellen komplett abgeschottete Umgebungen bereit;
• durch Emulation auch “falsche” Treiber nutzbar;
• starke Trennung zwischen zwei VMs und zwischen VM und Host;
• (teils deutlich) langsamer als echte Hardware.

Sandboxing / Container

• leichtere Alternative;
• bieten Kontrolle, Accounting, Isolation — schwächer, aber flexibler als bei VMs;
• sehr schnell, da keine Emulation und nur ein Kernel;
• großes Ökosystem an fertigen Paketen (Docker).

Beides kombinieren — das Ökosystem und die Flexibilität von Containern mit der Sicherheit von VMs (Kubernetes on VMs, Kata Containers, gVisor are the modern instances of that sentence).

Exam hooks

Likely questions, with where the answer lives:

1. “Nennen Sie drei Motivationen für Virtualisierung” → §1: isolation / aggregation / migration, each with its before-after picture.
2. “Welche Anforderungen muss ein VMM erfüllen?” → §4: four requirements, then the three sharing mechanisms and when to use which.
3. “Erklären Sie Ring Deprivileging und das 0/1/3- vs. 0/3-Modell” → §6.2.
4. “Warum ist IA-32 nicht virtualisierbar? Nennen Sie Löcher.” → §6.3; be able to name 3–4 of the six with one instruction each (POPF, CLI/STI, PUSHF/PUSH CS, CPUID, SGDT, LAR/LSL).
5. “Wie stopft man diese Löcher?” → §6.4: paravirtualisation (Xen), binary rewriting, ISA extension (VT-x, root/non-root, VMXON/VMXOFF).
6. “Warum ist Speicher doppelt virtualisiert? Zwei Lösungen.” → §7: trap-and-emulate vs. shadow page table, plus the CPU-uses-only-one-table observation.
7. “Beschreiben Sie den Pfad eines I/O-Zugriffs durch den VMM.” → §8.2, six steps, plus the two costs (extra hop, DMA copy/translate).
8. “Container vs. VMs: Vor- und Nachteile.” → §9.3, and the mechanism: namespaces (visibility) + cgroups (resources).
9. “Was macht PID 1 in einem Container?” → §10.2: namespace-local PIDs, so PID 1 exists once per namespace.

Sources

Source	Used for
raw/cloud-web-mobile/03_virtualisierung_sandboxing.pdf (42 p., PARTIAL, deck of 02.10.2026) + .md	all definitions, all diagrams, slide numbering; 19 slides were figure-only and were reconstructed from rendered pages
Popek & Goldberg, “Formal Requirements for Virtualizable Third Generation Architectures”, CACM 1974	the “sensitive instructions must trap” criterion behind §6.3/§6.4 (context for the IA-32 holes, not on the slide)
Robin & Irvine, “Analysis of the Intel Pentium’s Ability to Support a Secure Virtual Machine Monitor” (2000)	standard names of the IA-32 holes: ring aliasing, ring compression, address-space compression, non-trapping accesses, silent privilege-state change
Atlassian, Containers vs. VMs (image referenced on slide 31)	the containers-vs-VMs comparison picture
Linux kernel docs — namespaces(7), cgroups(7)	the 8 namespace kinds and the controller list filled in beyond the slide’s ellipses

Related: data-centers-and-iaas (why providers consolidate), cloud-history-and-terminology (service models — IaaS is exactly “a VM you rent”), concept map.