# KVM Architecture: Ein Blick in das Gehirn des Hypervisors

TL;DR / Management Summary KVM (Kernel-based Virtual Machine) ist kein eigenständiger Hypervisor, sondern ein Kernel-Modul, das Linux in einen Typ-1 Hypervisor verwandelt. In diesem Modul tauchen wir in die technische Realität ein: Wir verstehen den VM-Exit/VM-Entry Zyklus, lernen die VMCS-Datenstruktur kennen und analysieren, wie EPT (Extended Page Tables) den Speicherzugriff von VMs beschleunigen. Ein Senior Admin muss diese Mechanismen verstehen, um “Exit-Storms” zu diagnostizieren und maximale VM-Dichte zu erreichen.

# 1. Einführung & Architektur

Der Kernel als Dispatcher.

KVM nutzt die Hardware-Virtualisierungs-Features der CPU. Wenn eine VM einen privilegierten Befehl ausführen will, unterbricht die CPU die VM und übergibt die Kontrolle an KVM (VM-Exit).

# Der Ausführungs-Zyklus (Mermaid)

graph TD
    A[Guest VM: Running Code] --> B{Privileged Instruction / IO}
    B -->|VM-Exit| C[Host Kernel: KVM Handler]
    C --> D[Action: Emulate Device or Access RAM]
    D -->|VM-Entry| A
    subgraph "Context"
        E[VMCS: Virtual Machine Control Structure]
    end
    C --- E

# 2. VMCS: Der Personalausweis der VM

Virtual Machine Control Structure.

Jede VCPU hat einen eigenen Speicherbereich im Kernel (VMCS bei Intel, VMCB bei AMD).

• Inhalt: CPU-Register, Control-Bits und der Grund für den letzten VM-Exit.
• Performance: Je öfter der Kernel den VMCS laden und speichern muss, desto höher ist die Latenz (Context Switch).

# 3. Memory Virtualization: EPT und NPT

Direkter Zugriff auf den RAM.

Ohne Hardware-Unterstützung müsste KVM jede Speicheradresse der VM manuell übersetzen (Shadow Page Tables - extrem langsam).

• EPT (Extended Page Tables): Die CPU übernimmt die Übersetzung von Gast-Physisch zu Host-Physisch in Hardware.
• Vorteil: Nahezu Bare-Metal Performance beim RAM-Zugriff.

# 4. Day-2 Operations: Exit-Analyse

Den Hypervisor-Overhead messen.

Ein System mit zu vielen VM-Exits fühlt sich zäh an.

# Exits überwachen

# Zeigt die Gründe für VM-Exits live an (erfordert 'kvm_stat')
sudo kvm_stat

Achten Sie auf io_exits und mmio_exits. Hohe Werte deuten auf ineffiziente Gast-Treiber (kein VirtIO!) hin.

# 5. Troubleshooting & “War Stories”

Wenn die Abstraktion hinkt.

# Story 1: “Der Exit-Storm durch veraltete Treiber”

Symptom: Ein Host mit nur 2 VMs hat eine Load-Average von 10.0, obwohl die CPU-Last im Gast bei 5% liegt. Ursache: Die VM nutzt den emulierten e1000 Netzwerk-Treiber statt virtio. Jedes Netzwerkpaket erzeugt einen VM-Exit, den der Host mühsam emulieren muss. Lösung: Wechseln Sie alle Gast-Devices auf VirtIO.

# Story 2: “Das hängende Nested-Guest Setup”

Symptom: In einer VM, die selbst wieder VMs hostet (Nested Virtualization, z.B. für Tests), stürzen die inneren VMs ständig ab oder sind extrem instabil. Ursache: Der L1-Hypervisor gibt die VMCS-Daten nicht korrekt an den L0-Hypervisor weiter, oder die EPT-Beschleunigung ist in der zweiten Ebene nicht aktiv. Lösung: Aktivieren Sie Nested KVM auf dem Host: echo "options kvm-intel nested=1" > /etc/modprobe.d/kvm.conf.

# 6. Fazit & Empfehlung

• Wahl: Nutzen Sie immer moderne CPUs mit EPT/NPT Support.
• Treiber: VirtIO ist kein Luxus, sondern für KVM zwingend nötig, um VM-Exits zu minimieren.
• Wissen: Der Hypervisor ist nur ein Vermittler. Je weniger er tun muss (VM-Exits), desto schneller ist Ihr System.

# Anhang: Cheatsheet für Hypervisor-Admins