# RAM Optimization: Mehr VMs durch Ballooning und KSM

TL;DR / Management Summary Arbeitsspeicher ist oft der limitierende Faktor bei der Server-Virtualisierung. Mit Memory Overcommitment können wir mehr RAM an VMs vergeben, als physisch vorhanden ist. Wir nutzen dafür zwei geniale Kernel-Techniken: VirtIO Ballooning, das ungenutzten RAM aus den Gästen “absaugt”, und KSM (Kernel Samepage Merging), das identische Speicherseiten (z.B. der gleiche Linux-Kernel in 100 VMs) im RAM dedupliziert. Ein Senior Admin nutzt diese Hebel, um die Hardware-Effizienz zu verdoppeln, ohne die Stabilität zu gefährden.

# 1. Einführung & Architektur

Die Werkzeuge der Verdichtung.

1. Memory Ballooning: Ein Treiber im Gast (Balloon-Driver), der sich aufbläst und RAM vom Gast-Betriebssystem anfordert, um diesen an den Host zurückzugeben.
2. KSM: Ein Hintergrund-Thread des Kernels, der den RAM nach Duplikaten scannt und diese zu einer einzigen Seite verschmilzt.

# Die Architektur-Logik (Mermaid)

graph TD
    subgraph "SLES / Proxmox Host"
        A[Physical RAM: 64GB]
        B[KSM: Deduplication Engine]
        C[QEMU Process: VM 1]
        D[QEMU Process: VM 2]
    end
    subgraph "Guest VM 1"
        E[Guest OS]
        F[Balloon Driver: Inflated]
    end
    subgraph "Guest VM 2"
        G[Guest OS]
        H[Balloon Driver: Deflated]
    end
    F -->|Return RAM| A
    C --- B
    D --- B
    B -->|Savings| A

# 2. Memory Ballooning in der Praxis

Dynamische Zuweisung.

# Voraussetzungen

Der Gast braucht den virtio_balloon Treiber.

lsmod | grep virtio_balloon

# Steuerung vom Host (via virsh)

# Setze aktuelles RAM-Limit der VM auf 2GB (während sie läuft)
virsh setmem <vmid> 2G --live

Der Balloon-Treiber im Gast sorgt dafür, dass das OS den Speicher freigibt, indem er ihn selbst belegt und dem Hypervisor meldet.

# 3. Kernel Samepage Merging (KSM)

Deduplizierung im Arbeitsspeicher.

KSM ist ideal, wenn viele identische VMs laufen.

# Aktivierung am Host

echo 1 | sudo tee /sys/kernel/mm/ksm/run

# Erfolg messen

cat /sys/kernel/mm/ksm/pages_sharing
# Zeigt an, wie viele Seiten aktuell geteilt werden. 
# Rechnen: Wert * 4096 / 1024 / 1024 = Gesparte MB.

# 4. Day-2 Operations: Performance vs. Dichte

Den Preis der Effizienz kennen.

• KSM-Overhead: Der Scanner-Thread (ksmd) verbraucht CPU-Zyklen. Wenn der Server bereits bei 90% CPU-Last ist, deaktivieren Sie KSM.
• Ballooning-Latenz: Wenn eine VM plötzlich viel RAM braucht (Deflate), kann dies kurzzeitige Latenzen verursachen, bis der Host den Speicher physisch bereitstellt.

# 5. Troubleshooting & “War Stories”

Wenn der Host ‘lügt’.

# Story 1: “Der hängende SQL-Server durch Ballooning”

Symptom: Eine Datenbank in einer VM wird extrem langsam, obwohl top in der VM 50% freien RAM anzeigt. Ursache: Der Balloon-Treiber hat sich “aufgeblasen” und dem Gast-Betriebssystem suggeriert, dass nur noch wenig RAM da ist. Das Gast-OS hat daraufhin wichtige Datenbank-Caches gelöscht. Lösung: Nutzen Sie kein Ballooning für Datenbanken oder Applikationen mit großen In-Memory Caches. Setzen Sie dort festen RAM (Min = Max).

# Story 2: “Das KSM-Sicherheitsrisiko”

Symptom: Ein Security-Auditor bemängelt die Aktivierung von KSM. Ursache: Side-Channel Attacks (wie Rowhammer oder Cache-Timing). Durch das Teilen von Speicherseiten könnten theoretisch Informationen zwischen VMs fließen. Lösung: In hochsicheren Multi-Tenant Umgebungen (Public Cloud) wird KSM meist deaktiviert. In privaten Enterprise-RZ überwiegt oft der Nutzen der Kosteneinsparung.

# 6. Fazit & Empfehlung

• Standard: Aktivieren Sie Ballooning für Desktop-VMs und einfache Webserver.
• Performance: Deaktivieren Sie Ballooning für SAP, Oracle und SQL-Server.
• Wartung: Überwachen Sie den ksm-Status. Wenn die Ersparnis < 5% ist, schalten Sie den Dienst ab, um CPU zu sparen.

# Anhang: Cheatsheet