# Hypervisor Tuning: Den Host für den VM-Massenbetrieb härten

TL;DR / Management Summary Ein guter Hypervisor-Host (Proxmox, SLES, RHEL) ist mehr als nur ein Server mit viel RAM. Er muss so konfiguriert sein, dass er die Anforderungen hunderter Gast-Systeme gleichzeitig bedienen kann. In diesem Modul verlassen wir die VM-Sicht und optimieren den Host-Kernel: Wir tunen den CPU Governor, optimieren die Netzwerk-Bridges für geringste Latenz und stellen sicher, dass das Memory-Management des Hosts die Gäste nicht durch unnötiges Paging ausbremst.

# 1. Einführung & Architektur

Die Host-Gast-Konkurrenz.

Der Host-Kernel muss zwei Aufgaben balancieren:

1. Management: Der Host braucht CPU für sich selbst (I/O, Networking, GUI).
2. Payload: Die VMs brauchen 99% der CPU für ihre Rechenlast.

# Die Tuning-Ebenen (Mermaid)

graph TD
    A[Host Hardware] --> B[Kernel Scheduler: CPU Governor]
    A --> C[Memory Management: THP / Swap]
    A --> D[Network Stack: Bridge / Vhost]
    B --> E[VM Performance]
    C --> E
    D --> E
    subgraph "Optimization"
        F[Transparent Huge Pages: madvise]
        G[CPU: Performance Mode]
        H[Network: rx-usecs tuning]
    end
    F --- C
    G --- B
    H --- D

# 2. CPU Power Management

Keine Zeit für den Schlafmodus.

Standardmäßig nutzen viele Distributionen den powersave oder schedutil Governor. Für einen Hypervisor ist dies fatal, da das “Aufwachen” aus niedrigen C-States Latenz-Spikes in den VMs verursacht.

# Empfehlung: Performance Modus

# Auf allen Kernen aktivieren
echo "performance" | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

# 3. Network Stack: Die Bridge beschleunigen

Abkürzung durch den Kernel.

Wenn Sie Linux-Bridges (Artikel 143) nutzen, durchläuft jedes Paket den Netfilter-Layer (Iptables) des Hosts. Das kostet Zeit.

# Bridge-Netfilter deaktivieren

Falls Sie keine Firewall-Regeln auf dem Host für den VM-Traffic brauchen:

# In /etc/sysctl.d/99-bridge.conf
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-ip6tables = 0

# 4. Day-2 Operations: Memory Management

Kein Paging für Gäste.

Ein Hypervisor darf niemals swappen. Sobald der Host-Kernel RAM-Seiten einer VM auf die Disk schiebt, wird die VM unbenutzbar.

# Swappiness auf dem Host

# Extrem niedriger Wert, um Paging der VMs zu verhindern
sudo sysctl -w vm.swappiness=1

# 5. Troubleshooting & “War Stories”

Wenn die Optimierung zum Problem wird.

# Story 1: “Der hängende KVM-Prozess”

Symptom: VMs werden sporadisch für 1-2 Sekunden eingefroren. Der Host hat genug RAM und CPU. Ursache: Transparent Huge Pages (THP) (Artikel 388). Der Kernel-Thread khugepaged versucht im Hintergrund, RAM-Seiten der VMs zu bündeln und sperrt dabei kurzzeitig den Zugriff (Lock-Contention). Lösung: Stellen Sie THP auf madvise statt always. So nutzen nur Applikationen (wie QEMU), die explizit darum bitten, Huge Pages, und der Automatismus im Hintergrund ist weniger aggressiv.

# Story 2: “Interrupt-Storm auf 100Gbit”

Symptom: Ein Host mit 100Gbit Anbindung erreicht nur 20Gbit Durchsatz bei vielen kleinen Paketen. Die CPU-Last auf Kern 0 ist bei 100%. Ursache: Alle Netzwerk-Interrupts landen auf dem ersten CPU-Kern. Lösung: Nutzen Sie Multi-Queue VirtIO (Artikel 060) und stellen Sie sicher, dass irqbalance auf dem Host korrekt arbeitet oder pinnen Sie die IRQs manuell auf verschiedene Kerne (Artikel 389).

# 6. Fazit & Empfehlung

• Pflicht: CPU Governor auf performance.
• Wahl: Deaktivieren Sie bridge-nf-call-iptables, wenn Sie die Sicherheit auf Host-Ebene durch andere Maßnahmen (z.B. externe Hardware-Firewall) abdecken.
• Wartung: Überwachen Sie den Host mit virt-top und iostat -x, um rechtzeitig zu sehen, wenn eine VM die Host-Ressourcen monopolisiert.

# Anhang: Cheatsheet für den Hypervisor-Check