Linux · Tag 1 · Kapitel 04 von 10

Virtualisierung — vom Hypervisor zur VM

Bevor wir Rocky Linux installieren, müssen wir verstehen, wo es überhaupt laufen soll. Was ist eine VM? Was ist ein Hypervisor? Warum ist Virtualisierung das Rückgrat der modernen IT — und welche Stolperfallen lauern, bevor du klickst?

📚 Kapitel 04 ⏱️ ca. 35 min Lesezeit 🎯 Theorie + Praxis-Tipps
Inhalt dieses Kapitels
4.1

Was ist eine virtuelle Maschine?

Theorie

Eine virtuelle Maschine (VM) ist ein vollständiger Computer — Prozessor, Arbeitsspeicher, Festplatte, Netzwerkkarte — der nur in Software existiert. Sie läuft als Prozess auf deinem echten Rechner und glaubt selbst, sie sei ein echter, physischer PC.

Eine VM hat ihr eigenes BIOS, bootet ihr eigenes Betriebssystem und ist von deinem Host-System so weit getrennt, dass du sie crashen, neu starten oder löschen kannst, ohne dass dein Hauptsystem davon etwas merkt.

Die drei Schlüsselbegriffe

BegriffBedeutungIn unserem Kurs
Host Der echte, physische Computer, auf dem alles läuft Dein Laptop mit Windows 11
Guest / Gast Das Betriebssystem, das innerhalb der VM läuft Rocky Linux 9
Hypervisor Die Software, die VMs verwaltet und der Hardware zuteilt VMware Workstation Pro
┌─────────────────────────────────────────┐ │ HOST — dein echter Rechner │ │ Windows 11, 16 GB RAM, 512 GB SSD │ │ ┌─────────────────────────────────┐ │ │ │ HYPERVISOR │ │ │ │ VMware Workstation Pro │ │ │ │ ┌──────────────────────┐ │ │ │ │ │ VM (GUEST) │ │ │ │ │ │ Rocky Linux 9 │ │ │ │ │ │ - 2 vCPU │ │ │ │ │ │ - 2 GB vRAM │ │ │ │ │ │ - 20 GB vDisk │ │ │ │ │ │ - virt. NIC (NAT) │ │ │ │ │ └──────────────────────┘ │ │ │ └─────────────────────────────────┘ │ └─────────────────────────────────────────┘
📦
Mentales Modell

Stell dir eine VM wie eine App in einem Fenster vor. Nur dass diese „App“ eben ein komplettes Betriebssystem ist. Du kannst sie starten, schließen, einfrieren, klonen und kopieren — wie jede andere Datei auch.

4.2

Type-1 vs. Type-2 Hypervisor

Architektur

Es gibt zwei grundsätzlich verschiedene Bauweisen von Hypervisoren — sie unterscheiden sich darin, was zwischen Hardware und VM liegt:

▶ Tiefer einsteigen: Type-1 Hypervisoren (Bare-Metal)

Type-1 (Bare-Metal) Hypervisor

┌────────────────────────────────┐ │ VM │ VM │ VM │ │ ← Mehrere VMs gleichzeitig ├────────┴────────┴────────┴──────┤ │ Hypervisor (z.B. ESXi) │ ← läuft DIREKT auf Hardware ├─────────────────────────────────┤ │ Hardware (CPU, RAM, Disks) │ └─────────────────────────────────┘

Der Hypervisor IST quasi das Betriebssystem. Es gibt kein Windows oder Linux darunter — der Hypervisor spricht selbst direkt mit der Hardware. Das ist extrem schnell und sicher, aber unbequem als Arbeitsumgebung (du kannst auf so einem Server nicht Word starten).

Vertreter: VMware ESXi, Microsoft Hyper-V Server, Proxmox VE, KVM (Linux-Kernel-basiert), XenServer (ehemals Citrix Hypervisor), XCP-ng (Community-Fork).

Type-2 (Hosted) Hypervisor

┌────────────────────────────────┐ │ VM │ VM │ │ ├────────┴────────┴────────────┬─┤ │ Hypervisor (z.B. VMware │ │ │ Workstation) │ │ ├──────────────────────────────┘ │ │ Host-OS (Windows / macOS / Linux) ├─────────────────────────────────┤ │ Hardware │ └─────────────────────────────────┘

Der Hypervisor läuft als normales Programm auf einem ganz gewöhnlichen Betriebssystem. Das ist langsamer (eine Schicht mehr Overhead), aber sehr bequem: du klickst die VM auf, sie öffnet sich in einem Fenster neben deinem Browser.

Vertreter: VMware Workstation Pro / Player, Oracle VirtualBox, Parallels Desktop (macOS), QEMU.

▶ Tiefer einsteigen: Vergleichstabelle Type-1 vs. Type-2

Vergleich auf einen Blick

KriteriumType-1 (Bare-Metal)Type-2 (Hosted)
Läuft auf …direkt HardwareHost-OS
Performancenahe nativ~5–15 % Overhead
Boot-Zeitsofort startbereitHost-OS muss erst booten
EinsatzProduktion, RechenzentrumTest, Entwicklung, Lehre
BeispieleESXi, Hyper-V, Proxmox VE, KVM, XenServer/XCP-ngVMware Workstation, VirtualBox
Sicherheithöher (kleine Angriffsfläche)geringer (Host-OS als Risiko)
BedienungWeb-GUI / SSH / vCenterlokale GUI auf dem Host
🧪
Wussten Sie schon?

KVM (Kernel-based Virtual Machine) macht Linux selbst zum Type-1 Hypervisor. Wenn du Proxmox VE oder Red Hat Virtualization nutzt, steckt KVM darunter. KVM ist Open-Source und der Standard-Hypervisor der großen Cloud-Anbieter (AWS, Google Cloud nutzen KVM-Varianten).

4.4

Wichtige Konzepte: Snapshots und Isolation

Vorteile
💡
Worum geht es

Virtualisierung bringt zwei für die tägliche Praxis besonders wichtige Vorteile mit: Snapshots als Sicherheitsnetz und Isolation als Sandkasten.

Snapshots — Zeitreise auf Knopfdruck

Ein Snapshot ist ein eingefrorenes Abbild des VM-Zustands zu einem Zeitpunkt. Du kannst beliebig oft zurückspringen.

⚠️
Wichtige Unterscheidung

Snapshot ≠ Backup! Ein Snapshot liegt im selben Storage wie die VM. Wenn das Storage stirbt, sind Snapshot und VM gleichzeitig weg. Ein echtes Backup liegt außerhalb der VM-Plattform — auf einem anderen Storage, Cloud-Speicher oder Bandlaufwerk.

Snapshots sind für „ich probiere mal was aus, will aber zurückkönnen“. Backups sind für „der Hypervisor brennt“.

💡
Wichtig zu wissen: Isolation — Sandkasten ohne Risiko

Was in der VM passiert, bleibt in der VM. Du kannst dort:

  • Schadsoftware analysieren (Malware-Sandbox)
  • Verdächtige Mailanhänge öffnen
  • Neue Betriebssysteme testen
  • Mit rm -rf / experimentieren — Snapshot zurück, weiter geht's
4.5

Was steckt in einer VM? — Komponenten

Hardware (virtuell)
KomponenteWas ist das?Empfehlung für unsere VM
vCPU Virtuelle CPU-Kerne. Werden vom Hypervisor auf echte Kerne abgebildet. 2 vCPUs (von 4–8 echten)
vRAM Virtueller Arbeitsspeicher. Wird vom Host reserviert. 2 GB (von 16 GB)
vDisk Datei auf dem Host (.vmdk), erscheint in der VM als Festplatte 20 GB, „thin provisioned“ — wächst nur, wenn nötig
vNIC Virtuelle Netzwerkkarte. Wird einem Netzwerk-Modus zugeordnet. 1 vNIC im NAT-Modus
vGPU / Display Virtuelle Grafikkarte (für GUI) Standard (wir nutzen Konsole)
USB-Controller / Sound / Drucker Optionale Geräte Brauchen wir nicht — vor Installation entfernen
💡
Faustregel: vRAM

Weise einer VM nie mehr als 50 % des Host-RAM zu, sonst würgst du dein Host-System ab. Bei 8 GB Host-RAM → maximal 4 GB an die VM, besser 2 GB. Linux-Minimal läuft problemlos in 1–2 GB.

💡
Faustregel: vCPU

Weniger vCPU ist oft besser als mehr. Lieber 2 vCPU vergeben — dann läuft die VM geschmeidiger.

▶ Tiefer einsteigen: Was ist Co-Scheduling?

Wenn du 4 vCPU zuweist, muss der Hypervisor 4 echte Kerne gleichzeitig frei haben, um die VM zu rechnen (co-scheduling). Sind nur 2 Kerne frei, muss er warten, bis weitere 2 frei werden — die VM bekommt also weniger CPU-Zeit, je mehr vCPUs sie eigentlich „besitzt". Deshalb kann eine 4-vCPU-VM auf einem stark belegten Host langsamer laufen als dieselbe VM mit 2 vCPUs.

4.6

Netzwerkmodi: NAT, Bridged, Host-Only

Wichtig!

Die häufigste Quelle für Frust beim VM-Setup ist das Netzwerk. Wir gehen die drei wichtigsten Modi gemeinsam durch.

NAT — Network Address Translation

Internet │ │ ┌──┴──────────────────────────────────┐ │ Host-PC (z.B. 192.168.0.42) │ │ │ │ ┌──────── NAT-Router ─────────┐ │ │ │ (vom Hypervisor erzeugt) │ │ │ │ z.B. 192.168.211.1 │ │ │ │ │ │ │ │ ┌─────────────────┐ │ │ │ │ │ VM │ │ │ │ │ │ 192.168.211.128 │ │ │ │ │ └─────────────────┘ │ │ │ └─────────────────────────────┘ │ └─────────────────────────────────────┘
  • Die VM hat eine eigene private IP, vergeben vom Hypervisor
  • Kommunikation nach außen läuft über den Host wie durch einen Router
  • Die VM kann ins Internet, andere Geräte im LAN sehen die VM aber nicht
  • Vorteil: Funktioniert immer (auch in fremden WLANs), ohne Konfiguration
  • Standard für unseren Kurs!
▶ Tiefer einsteigen: Andere Netzwerkmodi (Bridged, Host-Only)

Bridged — direkter LAN-Zugang

┌───── LAN / Router ─────┐ │ 192.168.0.0/24 │ │ │ ┌──────┴───────┐ ┌──────┴───────┐ │ Host │ │ VM (Bridged)│ │ 192.168.0.42 │ │ 192.168.0.55 │ ← eigene IP im LAN! └──────────────┘ └──────────────┘
  • Die VM hängt direkt am physischen Netzwerk, als wäre sie ein eigener PC
  • Bekommt eine IP vom DHCP-Server deines LANs (z.B. der Fritzbox)
  • Andere Geräte im LAN können die VM sehen
  • Vorteil: realistisches Setup, andere Rechner können auf VM-Services zugreifen
  • Nachteil: braucht funktionierendes DHCP im LAN — in fremden Netzwerken oft Probleme

Host-Only — privates Mini-Netz nur zum Host

┌─────────────────────────┐ │ Host │ │ 192.168.56.1 │ │ │ │ │ │ (kein Internet) │ │ │ │ │ ┌───┴────────┐ │ │ │ VM │ │ │ │ 192.168.56.10 │ │ └────────────┘ │ └─────────────────────────┘
  • Privates Netzwerk nur zwischen Host und VM
  • Kein Internet-Zugang!
  • Nützlich für isolierte Labore: mehrere VMs in einem virtuellen Netz, das niemand von außen sieht

Vergleichstabelle

ModusInternet?Sichtbar im LAN?IP-QuelleStabil in fremdem WLAN?
NAT✅❌Hypervisor (DHCP)✅
Bridged✅✅echter LAN-DHCP⚠️
Host-Only❌❌Hypervisor (DHCP)✅
⚠️
Falle: Bridged ohne DHCP

Bridged setzt voraus, dass im LAN ein DHCP-Server läuft, der freie IPs vergibt. In manchen Firmennetzen ist das nicht der Fall — dort bekommst du in der VM gar keine IP und wunderst dich. Wenn unsicher: bleibe bei NAT.

4.7

Snapshots — Theorie und Praxis

Lifesaver
▶ Tiefer einsteigen: Wie Snapshots technisch funktionieren (Delta-Dateien)

Was ist ein Snapshot technisch?

Wenn du einen Snapshot erstellst, friert der Hypervisor die bisherige Disk ein und schreibt alle neuen Änderungen in eine Delta-Datei. Beim „Zurückspringen“ verwirft er einfach die Delta-Datei.

Vor Snapshot: VM ─→ disk.vmdk (alles drin) Nach Snapshot: VM ─→ disk.vmdk (read-only, base) ↓ delta_001.vmdk (alle neuen Schreibvorgänge)

Wann setzt man Snapshots ein?

  • Vor riskanten Änderungen (Kernel-Update, neue Software, Migrations-Skript)
  • Als Test-Anker beim Experimentieren („zurück zum frischen System“)
  • Vor Sicherheits-Patches, falls etwas auf Anhieb nicht startet

Wie setzt man Snapshots ein? (VMware Workstation)

  1. VM → Snapshot → Take Snapshot (oder Strg+M)
  2. Aussagekräftigen Namen geben, z.B. vor-dnf-update
  3. Beschreibung mit Datum und Grund hinzufügen
  4. Snapshot Manager öffnen (VM → Snapshot → Snapshot Manager) — du siehst einen Baum aller Snapshots
  5. Zum Zurückspringen: gewünschten Snapshot auswählen → Go To
⚠️
SNAPSHOT IST KEIN BACKUP

Sag das in 6 Monaten noch dreimal: Ein Snapshot ist kein Backup. Wenn der Host stirbt, sind Snapshot und VM gleichzeitig weg. Snapshots leben für Stunden bis Tage — Backups für Wochen bis Jahre.

▶ Tiefer einsteigen: Die 3-2-1-Backup-Regel

Backups gehören auf ein anderes Storage, idealerweise mit der 3-2-1-Regel: 3 Kopien, auf 2 verschiedenen Medien, 1 davon extern.

💡
Praxis-Tipp

Mehr als 3 Snapshots pro VM solltest du nicht stapeln, sonst wird die Disk-Performance spürbar langsamer (jeder Schreibzugriff geht durch alle Delta-Schichten). Alte Snapshots regelmäßig löschen („committen“ heißt das in der VMware-Sprache).

4.8

Hardware-Mindestanforderungen für Virtualisierung

Profi-Tipp
KomponenteMinimumEmpfehlungWarum?
CPU 2 Kerne mit VT-x / AMD-V 4+ Kerne, möglichst mit Hyper-Threading VMs brauchen echte Kerne, kein Trick funktioniert ohne Hardware-Virtualisierung
RAM 8 GB 16 GB+ Host braucht 4–6 GB, je VM mindestens 1–2 GB extra
Disk 30 GB frei SSD mit 100+ GB frei HDDs sind quälend langsam für VMs — SSD verzehnfacht das Bootverhalten
BIOS/UEFI VT-x / AMD-V aktiv plus VT-d (für Passthrough) Ohne VT-x lädt VMware Workstation gar keine VM
⬇️
VMware & Rocky Linux herunterladen

Alle Downloads, die du für diesen Kurs brauchst, findest du gebündelt auf der Setup-Seite — VMware Workstation/Fusion, Rocky-ISO (x86_64 und aarch64), plus später Ubuntu Server und Windows Server.

⚠️
Lizenz-Hinweis VMware

Seit Mai 2024 ist VMware Workstation Pro / Fusion Pro für die private Nutzung kostenlos. Für die kommerzielle Nutzung (auch in Firmen-Schulungsräumen) ist weiterhin eine Lizenz erforderlich. Bei der Installation "Use for Personal Use" wählen, wenn der Kurs privat absolviert wird; sonst die Firmen-Lizenz hinterlegen.

VT-x / AMD-V prüfen unter Windows

PowerShell 
# Im PowerShell-Fenster:
systeminfo | findstr /C:"Hyper-V"

# Erwartet (Auszug):
# Hyper-V-Anforderungen:
#   VM-Überwachungsmodus-Erweiterungen: Ja
#   Virtualisierung in Firmware aktiviert: Ja      ← muss "Ja" sein!
#   Adressübersetzung der zweiten Ebene: Ja
#   Datenausführungsverhinderung verfügbar: Ja

Falls dort „Nein“ steht: Im BIOS/UEFI nach den Einträgen „Intel Virtualization Technology“, „VT-x“ oder „SVM Mode“ (AMD) suchen und aktivieren.

4.9

Häufige Fehler — und wie du sie vermeidest

Stolperfallen
❌
Fehler 1 — „VT-x ist deaktiviert“

Symptom: VMware oder VirtualBox startet die VM nicht und meldet „This host does not support Intel VT-x / no hardware virtualization“.

Ursache: Im BIOS/UEFI ist die Hardware-Virtualisierung abgeschaltet. Bei vielen Business-Laptops ist sie ab Werk aus.

Lösung: BIOS aufrufen (meist F2, F10 oder Entf beim Boot), Option Intel VT-x oder SVM Mode aktivieren, speichern, neu starten. Zusätzlich unter Windows: Hyper-V deaktivieren (über „Windows-Features aktivieren oder deaktivieren“), sonst blockt es VMware Workstation.

❌
Fehler 2 — Zu wenig RAM zugewiesen

Symptom: Rocky bootet ewig, hängt bei „Loading initial ramdisk“ oder stürzt mitten in der Installation ab.

Ursache: Du hast der VM nur 512 MB oder 1 GB gegeben. Selbst die Minimal-Installation braucht ~1.5 GB.

Lösung: VM herunterfahren, in den Settings auf 2048 MB erhöhen, neu starten.

❌
Fehler 4 — Ethernet im Installer ausgeschaltet

Symptom: Rocky-Installation erfolgreich, aber nach dem Boot kein Netzwerk, dnf update findet keinen Server.

Ursache: Im Anaconda-Installer war der Ethernet-Schalter auf AUS. Damit ist die Netzwerkverbindung deaktiviert konfiguriert.

Lösung: Entweder neu installieren mit aktivem Ethernet, oder als root nmcli connection up ens160 (Interface-Name ggf. mit ip a nachsehen). Behandeln wir morgen ausführlicher.

▶ Tiefer einsteigen: Weitere VM-Fehler
❌
Fehler 3 — Bridge ohne DHCP / kein Netzwerk

Symptom: In der VM funktioniert ping 8.8.8.8 nicht. ip a zeigt keine IP-Adresse.

Ursache: Du nutzt Bridged-Mode, aber der LAN-DHCP-Server ist nicht erreichbar (z.B. WLAN-Roaming, Firmennetz mit MAC-Filter).

Lösung: Netzwerkadapter auf NAT umstellen. NAT funktioniert immer, ohne externes DHCP.

❌
Fehler 5 — Snapshot-Spaghetti

Symptom: VM startet sehr langsam, Disk-I/O ist quälend lahm.

Ursache: Du hast über Wochen 8+ Snapshots gestapelt. Jeder Schreibzugriff geht durch alle Delta-Dateien.

Lösung: Im Snapshot Manager alte Snapshots löschen („Commit“). Faustregel: nicht mehr als 3 aktive Snapshots gleichzeitig.

🎓
Trainer-Hinweis

Geht diese fünf Fehler vor der praktischen Installation einmal kurz mündlich durch — die meisten Teilnehmer rennen sonst in genau diese Fallen. Besonders VT-x ist bei Business-Laptops oft ab Werk aus.

🎯

Kontrollfragen zum Kapitel

Selbst-Check
  1. Definiere in eigenen Worten die Begriffe Host, Guest und Hypervisor.
  2. Warum ist NAT der sicherere Standard für Lern-VMs in wechselnden WLANs gegenüber Bridged?
  3. Was bedeutet die Aussage „Snapshot ≠ Backup“ konkret?
  4. Was muss im BIOS/UEFI aktiviert sein, damit überhaupt VMs starten können?
  5. Warum ist es eine schlechte Idee, einer VM auf einem 8-GB-Host 6 GB RAM zuzuweisen?
  1. Host = physischer PC + dessen OS. Guest = das Betriebssystem, das in der VM läuft. Hypervisor = die Software, die VMs erzeugt und verwaltet (z.B. VMware Workstation).
  2. Weil NAT keinen externen DHCP-Server braucht — die Adressvergabe macht der Hypervisor selbst. Bridged scheitert in Netzen ohne (oder mit restriktivem) DHCP.
  3. Ein Snapshot liegt im selben Storage wie die VM. Stirbt das Storage, sind Snapshot und VM gleichzeitig weg. Ein Backup liegt extern, idealerweise nach der 3-2-1-Regel.
  4. Hardware-Virtualisierung: Intel VT-x bzw. AMD-V (SVM Mode). Bonus für Passthrough: VT-d / IOMMU.
  5. Weil das Host-OS selbst 3–4 GB braucht. Bei 6 GB an die VM bleiben dem Host nur 2 GB — er muss massiv auf die Auslagerungsdatei (Swap) zugreifen und wird langsam. Faustregel: VM bekommt maximal 50 % des Host-RAM.