# KVM & QEMU Architektur: Die Engine hinter den Kulissen

TL;DR / Management Summary Proxmox VE nutzt KVM (Kernel-based Virtual Machine), um den Linux-Kernel in einen vollwertigen Typ-1 Hypervisor zu verwandeln. Während KVM die CPU- und Speicher-Virtualisierung übernimmt, emuliert QEMU die restliche Hardware. Für Senior Admins gibt es hier nur ein Ziel: Minimierung des Overheads. Dies erreichen wir durch VirtIO (Para-Virtualisierung) und das Durchreichen nativer CPU-Instruktionen (CPU Type: Host). Wer emulierte IDE-Controller oder E1000-Karten nutzt, verschenkt 80% der möglichen Performance.

# 1. Die Architektur: Wer macht was?

Das Zusammenspiel zwischen Linux-Kernel, KVM und QEMU ist ein Meisterwerk der Software-Technik.

# Schichtenmodell der Virtualisierung (Mermaid)

graph TD
    subgraph U[User Space]
        Q[QEMU Prozess - VM 101]
        QA[QEMU Guest Agent]
    end

    subgraph K[Kernel Space / Host OS]
        KVM[KVM Kernel Modul]
        DRV[Host Treiber: ZFS, Network, GPU]
        SCHED[Linux Scheduler]
    end

    subgraph H[Hardware]
        CPU[CPU mit VT-x / AMD-V]
        RAM[Physical RAM]
        NIC[Physical NIC]
    end

    Q <--> KVM
    KVM <--> CPU
    Q <--> DRV
    SCHED --> Q
    DRV --> NIC
    
    style KVM fill:#f96,stroke:#333
    style CPU fill:#9f9,stroke:#333

1. KVM (Kernel Modul): Nutzt die Hardware-Virtualisierungs-Features (Intel VT-x, AMD-V) der CPU. Es erlaubt der CPU, in einem speziellen “Guest-Mode” zu arbeiten, in dem Instruktionen direkt und ohne Software-Eingriff ausgeführt werden.
2. QEMU: Läuft als normaler Prozess im User-Space. QEMU stellt die virtuelle Umgebung bereit: Erstellt den Adressraum im RAM, emuliert BIOS/UEFI und stellt virtuelle Hardware (PCI-Bus, Grafikkarte, Controller) zur Verfügung.

# 2. Emulation vs. Para-Virtualisierung (VirtIO)

Der größte Performance-Killer ist die Emulation alter Hardware.

# Warum Emulation langsam ist

Wenn eine VM eine klassische Intel E1000 Netzwerkkarte emuliert, muss QEMU jedes einzelne Register dieser Hardware in Software nachbauen. Jedes gesendete Paket führt zu unzähligen CPU-Kontextwechseln zwischen Guest, QEMU und Kernel.

# Die VirtIO-Lösung

VirtIO ist ein Standard für para-virtualisierte Treiber. Die VM “weiß”, dass sie in einer virtuellen Umgebung läuft und nutzt einen hocheffizienten Ring-Puffer im RAM, um Daten direkt an den Host-Kernel zu übergeben.

# VirtIO Datenfluss (Mermaid)

graph LR
    subgraph G[Guest OS]
        APP[Applikation] --> VDRV[VirtIO Driver]
    end

    subgraph H[Host / Proxmox]
        VDRV -- "Shared Ring Buffer" --> VBACK[VirtIO Backend - vhost-net]
        VBACK --> PNIC[Physical NIC]
    end

    style VDRV fill:#9f9,stroke:#333
    style VBACK fill:#f96,stroke:#333

Vorteile von VirtIO:

• Netzwerk: 10G/40G Durchsatz bei minimaler CPU-Last.
• Storage (VirtIO-SCSI): Unterstützt Multi-Queue, TRIM (Discard) und IO-Threads.

# 3. CPU-Design: vCPUs, Topologie und NUMA

Die Konfiguration der CPU entscheidet darüber, ob eine VM “stottert” oder fließt.

# CPU-Typ: ‘Host’ ist Pflicht

Standardmäßig nutzt Proxmox den Typ kvm64. Dies ist ein kleinster gemeinsamer Nenner für die Live-Migration.

• Empfehlung: Wenn Ihre Cluster-Knoten identische CPUs haben, nutzen Sie immer CPU Type: Host.
• Warum? Nur so erhält die VM Zugriff auf Instruktionen wie AES-NI (Verschlüsselung) oder AVX (Berechnungen).

# NUMA (Non-Uniform Memory Access)

Moderne Server haben zwei oder mehr CPUs. Jede CPU hat ihren “eigenen” lokalen RAM. Der Zugriff auf den RAM der anderen CPU ist langsam.

• Senior Tipp: Aktivieren Sie die Checkbox NUMA in den VM-Optionen, wenn die VM mehr als eine vCPU-Socket-Konfiguration hat oder sehr viel RAM nutzt. Proxmox versucht dann, die VM-Prozesse und ihren Speicher auf demselben physischen Sockel zu halten.

# 4. Day-2 Operations: Den Guest Agent beherrschen

Der QEMU Guest Agent (qemu-ga) ist eine kleine Software, die innerhalb der VM installiert werden muss.

1. Dateisysteme einfrieren (Quiescing): Ermöglicht konsistente Backups im laufenden Betrieb. Vor dem Snapshot werden alle Caches der VM auf die Disk geflasht.
2. IP-Adressen: Zeigt die tatsächlichen IP-Adressen der VM direkt in der Proxmox-GUI an.
3. Graceful Shutdown: Ermöglicht einen sauberen Shutdown über den Agenten, anstatt nur ein ACPI-Signal zu senden.

Installation (Ubuntu/Debian):

apt update && apt install qemu-guest-agent -y
systemctl start qemu-guest-agent

Vergessen Sie nicht, den Agenten auch in den VM-Optionen in Proxmox zu aktivieren!

# 5. Troubleshooting & “War Stories”

# Die “Boot-Loop” Falle

Szenario: Eine VM wurde von einem alten VMware-Host zu Proxmox migriert und startet nicht. Ursache: Die VM war auf UEFI (OVMF) konfiguriert, aber in Proxmox wurde eine “SeaBIOS” VM angelegt. Lösung: Umstellung auf OVMF und Hinzufügen eines EFI-Disks in der Hardware-Konfiguration.

# Der stotternde Terminal-Server

Szenario: Benutzer klagten über “Lag” auf einem virtuellen Windows-Terminalserver. Entdeckung: Die CPU-Last auf dem Host war niedrig, aber die VM-Option “Display” stand auf Standard VGA. Lösung: Umstellung auf VirtIO-GPU und Nutzung des SPICE Protokolls. Die Bildwiederholrate stieg massiv an, da die Grafikoperationen nun para-virtualisiert wurden.

# 6. Experten-Checkliste für KVM-VMs

• [ ] CPU Type: Host konfiguriert (für AES-NI)?
• [ ] VirtIO-SCSI als Controller gewählt?
• [ ] VirtIO-net als Netzwerkkarte aktiv?
• [ ] Discard/TRIM aktiviert (besonders auf SSD/Thin-Provisioning)?
• [ ] QEMU Guest Agent installiert und in Proxmox aktiviert?
• [ ] IO-Thread für die Systemdisk aktiviert (verbessert Parallelität)?

# Anhang: Referenzen & Links

• Proxmox VE: Virtual Machine Management (Official)
• KVM Project Home
• QEMU Documentation
• Red Hat: VirtIO Performance Tuning