Proxmox Best Practice Teil 2 - Storage: LVM-Thin und noch viel mehr

Die Storage-Grundlagen in Proxmox richtig verstehen und deren Vorteile gezielt nutzen.

Was ist Storage in Proxmox?

Storage in Proxmox sind die verschiedenen Speicherorte, wo deine Daten landen, davon gibt es diverse in einem normalen Setup:

VM-Festplatten (Images): Die virtuellen HDDs/SSDs deiner VMs
Container-Dateisysteme (Rootdir): Das Dateisystem der LXC-Container
ISO-Images: Installations-CDs/DVDs für VMs
Templates: Vorgefertigte VM- oder Container-Images
Backups: Gesicherte VM/Container-Daten
Snippets: Cloud-Init-Konfigurationen, Hooks, etc.

Fangen wir klassisch an mit LVM-Thin: Dein Schweizer Taschenmesser der Speicherverwaltung

Was ist LVM-Thin? Think of it as „intelligente Speicherzuteilung“. Statt sofort den gesamten Speicherplatz zu reservieren, wird nur der tatsächlich genutzte Platz belegt.

Praktisches Beispiel: Ihr erstellt eine 100GB VM, aber sie nutzt anfangs nur 10GB. Bei klassischer Speicherung wären sofort 100GB belegt, mit LVM-Thin nur die tatsächlich genutzten 10GB.

LVM-Thin Pool einrichten

# Volume Group erstellen (falls noch nicht vorhanden)
pvcreate /dev/sdb
vgcreate pve-data /dev/sdb

# Thin Pool erstellen
lvcreate -L 100G -n data pve-data
lvconvert --type thin-pool pve-data/data

# In Proxmox konfigurieren
pvesm add lvmthin local-lvm --thinpool data --vgname pve-data --content images,rootdir

Storage-Konfiguration in der Praxis

Für Einsteiger: Proxmox richtet standardmäßig lokalen Storage ein:

local: Für ISO-Images, Templates, Backups
local-lvm: Für VM-Festplatten

Für Fortgeschrittene: Verschiedene Storage-Typen kombinieren:

# NFS für gemeinsame Templates
pvesm add nfs shared-templates --server 192.168.1.100 --export /exports/templates --content iso,template

# Ceph für hochverfügbaren Storage (Cluster)
pvesm add ceph ceph-storage --pool vm-storage --content images

# ZFS für lokale Hochperformance
zpool create -f tank mirror /dev/sdc /dev/sdd
pvesm add zfspool zfs-local --pool tank --content images,rootdir

Sehen wir uns auch dass mal weiter im Detail an, denn auch dass Das ist einer der kritischsten Bereiche für Performance und Zuverlässigkeit!

Welche Storage-Typen hab ich denn aktuell in meinem Proxmox Setup?

# Alle konfigurierten Storage anzeigen
pvesm status

# Beispiel-Ausgabe:
Name     Type     Status   Total    Used   Available   %
local    dir      active   50.0GB   20.0GB  30.0GB    40.00%
local-lvm lvmthin active  500.0GB  100.0GB 400.0GB    20.00%

LVM-Thin: Das Herzstück verstehen

Was macht LVM-Thin besonders?

Traditionelle Speicherung (Thick Provisioning):

# VM bekommt 100GB Disk
qm set 100 --scsi0 local-lvm:100

# Problem: 100GB werden SOFORT vom Storage belegt
# Auch wenn VM nur 5GB tatsächlich nutzt!

Bessere Variante LVM-Thin (Thin Provisioning):

# VM bekommt 100GB Disk
qm set 100 --scsi0 local-lvm:100

# Vorteil: Nur tatsächlich genutzte Daten belegen Speicher
# VM nutzt 5GB → nur 5GB belegt
# VM nutzt 50GB → nur 50GB belegt

LVM-Thin Pool einrichten – Schritt für Schritt

Schritt 1: Volume Group vorbereiten

# Festplatte partitionieren (ACHTUNG: Daten werden gelöscht!)
fdisk /dev/sdb
# Partition typ: 8e (Linux LVM)

# Physical Volume erstellen
pvcreate /dev/sdb1

# Volume Group erstellen oder erweitern
vgcreate pve-data /dev/sdb1
# oder zu bestehender VG hinzufügen:
# vgextend pve /dev/sdb1

Schritt 2: Thin Pool erstellen

# Thin Pool erstellen (80% der verfügbaren Größe)
VGSIZE=$(vgs --noheadings -o vg_size --units g pve-data | tr -d ' G')
POOLSIZE=$(echo "$VGSIZE * 0.8" | bc | cut -d. -f1)

lvcreate -L ${POOLSIZE}G -n data pve-data
lvconvert --type thin-pool pve-data/data

# Metadata-Pool-Größe anpassen (falls nötig)
lvextend --poolmetadatasize +1G pve-data/data

Schritt 3: In Proxmox integrieren

# Storage in Proxmox hinzufügen
pvesm add lvmthin local-lvm-thin \
  --thinpool data \
  --vgname pve-data \
  --content images,rootdir

LVM-Thin Konfiguration optimieren

Auto-Extend konfigurieren

In diesem Beispiel erweitert sich eure LVM-Thin Speicherzuweisung automatisch um weitere 20% Speichermenge, sobald der belegte Speicher die 80% Marke erreicht hat. Grundsätzlich eine feine Sache, muss man aber auch zum einen ein Auge drauf und zum anderen den Speicherplatz „frei“ haben für.

# /etc/lvm/lvm.conf anpassen
cat >> /etc/lvm/lvm.conf << 'EOF'
activation {
    thin_pool_autoextend_threshold = 80
    thin_pool_autoextend_percent = 20
}
EOF

# Bedeutung:
# Bei 80% Füllstand automatisch um 20% erweitern

Metadata-Pool optimieren

Auch die gespeicherten Metadaten wollen irgendwo abgelegt werden.

# Metadata-Pool-Größe prüfen
lvs -a | grep metadata

# Bei Bedarf vergrößern
lvextend --poolmetadatasize +1G pve-data/data

# Warum wichtig? Metadata speichert:
# - Welche Thin Volumes existieren
# - Welche Blöcke belegt sind
# - Snapshot-Informationen

Gehen wir hier mal weit ins Detail, was die Befehle überhaupt bedeuten:

Der erste Befehl, # Metadata-Pool-Größe prüfen lvs -a | grep metadata, dient dazu, den aktuellen Status der Metadaten zu überprüfen:

lvs -a: Listet alle logischen Volumes auf, einschließlich der internen, wie dem Metadaten-Volume und | grep metadata: Filtert die Ausgabe so, dass nur Zeilen angezeigt werden, die das Wort „metadata“ enthalten.

Der zweite Befehl, # Bei Bedarf vergrößern lvextend --poolmetadatasize +1G pve-data/data, vergrößert das Metadaten-Volume um 1 Gigabyte Speicher, falls es zu voll wird mit lvextend: Ein Befehl zum Erweitern eines logischen Volumes, --poolmetadatasize +1G: Diese Option zielt speziell auf das Metadaten-Volume des Thin Pools ab und vergrößert es um 1 GB. Und natürlich noch der Pfadagabe pve-data/data: Dies ist der Pfad zum Thin Pool, der erweitert werden soll. In diesem Beispiel ist pve-data die Volume Group und data euer Thin Pool.

Warum Metadaten so wichtig sind

Metadaten sind sozusagen das Inhaltsverzeichnis deines Thin Pools. Sie speichern alle wichtigen Informationen, damit Proxmox weiß, wo sich welche Daten befinden. Wenn der Speicherplatz für Metadaten voll ist, kann man keine neuen VMs, Container oder Snapshots mehr erstellen, und bestehende VMs können möglicherweise keine neuen Daten mehr schreiben.

Over-Provisioning verstehen

Grundsäztlich ist es möglich euren VMs oder LXC im System viel mehr Speicher zuzuweisen als tatsächlich verfügbar ist, so lang dieser nicht benutzt wird auch völlig unproblematisch.

# 500GB Thin Pool
# 10× 100GB VMs = 1000GB virtuell
# Aber nur tatsächlich genutzte Daten belegen Platz

# Problem bei 100% Auslastung:
# Alle VMs bekommen I/O-Fehler!

Monitoring und Alerts

Ein Auge muss man aber unbedingt darauf haben, denn sobald der Speicher „überläuft“ werfen euch sonst eure VMs und LXC dann nur noch I/O-Fehler.

# Script für Thin Pool Monitoring
cat > /usr/local/bin/thin-pool-monitor.sh << 'EOF'

#!/bin/bash
USAGE=$(lvs --noheadings -o data_percent pve-data/data | tr -d ' %')
METADATA=$(lvs --noheadings -o metadata_percent pve-data/data | tr -d ' %')

if [ "$USAGE" -gt 90 ]; then
    logger "WARNING: Thin pool data usage: ${USAGE}%"
    echo "Thin pool ist voll: ${USAGE}%" | \
        mail -s "Proxmox Storage Alert" admin@company.com
fi

if [ "$METADATA" -gt 90 ]; then
    logger "WARNING: Thin pool metadata usage: ${METADATA}%"
fi
EOF

# Cronjob alle 5 Minuten
echo "*/5 * * * * root /usr/local/bin/thin-pool-monitor.sh" >> /etc/crontab

In diesem Beispiel würde ein Bash-Skript darauf achten dass der Speicher nicht über 90% Füllstand steigt, ansonsten die Warnmeldung „Thin pool ist voll mit der aktuellen Prozentangabe melden und an den admin@company.com per eMail senden. Zusätzlich wird das gleiche für den Metadatenspeicher geloggt.
Der Cronjob in der letzten Zeile sorgt dafür dass das Monitoring-Skript alle 5 Minuten ausgeführt wird.

Thin Pool erweitern

# Neue Festplatte hinzufügen
pvcreate /dev/sdc1
vgextend pve-data /dev/sdc1

# Thin Pool vergrößern
lvextend -L +200G pve-data/data

Praktische Anwendungsfälle

Template-basierte VM-Erstellung

# Template erstellen
qm create 9000 --memory 2048 --scsi0 local-lvm:20
# Template konfigurieren...
qm template 9000

# Linked Clones erstellen (super schnell!)
qm clone 9000 101 --name web-server-1
qm clone 9000 102 --name web-server-2

# Linked Clone nutzt nur zusätzlichen Speicher für Änderungen
lvs
# vm-9000-disk-0    pve-data Vwi---tz--  20.00g data         # Template
# vm-101-disk-0     pve-data Vwi-aotz--  20.00g data   vm-9000-disk-0  # Clone
# vm-102-disk-0     pve-data Vwi-aotz--  20.00g data   vm-9000-disk-0  # Clone

Snapshot-Management

# Snapshot vor wichtigen Änderungen
qm snapshot 100 before-update

# Snapshots auflisten
qm listsnapshot 100

# Zu Snapshot zurückkehren
qm rollback 100 before-update

# Snapshot löschen
qm delsnapshot 100 before-update

NFS Storage: Geteilter Speicher für den Proxmox-Cluster

NFS (Network File System) ist einer der Klassiker unter den Netzwerk-Storage-Lösungen und zB. für Proxmox-Umgebungen geeignet, in denen ihr Storage zwischen mehreren Nodes teilen möchtet. Das Besondere: NFS basiert auf dem Directory-Backend, bringt aber den Vorteil mit, dass Proxmox die NFS-Shares automatisch mounten kann.

Was macht NFS in Proxmox besonders?

Der große Pluspunkt von NFS in Proxmox: Ihr müsst nicht manuell in der /etc/fstab herumfummeln! Proxmox übernimmt das komplette Mount-Management für euch. Das Backend kann sogar testen, ob der NFS-Server online ist und euch alle verfügbaren Exports anzeigen.

Das ist besonders praktisch, wenn ihr:

Shared Storage für Live-Migration braucht
Templates und ISOs zentral verwalten wollt
Einfache Backup-Lösungen implementieren möchtet
Kostengünstige Storage-Erweiterung benötigt

NFS Storage konfigurieren – Schritt für Schritt

Die Grundkonfiguration

# NFS Storage in Proxmox hinzufügen
pvesm add nfs iso-templates \
  --server 10.0.0.10 \
  --export /space/iso-templates \
  --content iso,vztmpl \
  --options vers=3,soft

Was passiert hier im Detail?

--server 10.0.0.10: Das ist euer NFS-Server. Pro-Tipp: Nutzt lieber IP-Adressen statt DNS-Namen, um DNS-Lookup-Verzögerungen zu vermeiden. Falls ihr doch DNS verwenden wollt, tragt den Server in die /etc/hosts ein:

echo "10.0.0.10 nfs-server.local" >> /etc/hosts

--export /space/iso-templates: Der NFS-Export-Pfad auf dem Server. Den könnt ihr übrigens vorher scannen:

# Verfügbare NFS-Exports anzeigen
pvesm scan nfs 10.0.0.10

# Beispiel-Ausgabe:
# /space/iso-templates
# /space/vm-storage  
# /space/backups

--content iso,vztmpl: Legt fest, was auf diesem Storage gespeichert werden darf:

iso: ISO-Images für VM-Installationen
vztmpl: LXC-Container-Templates

--options vers=3,soft: Hier wird’s interessant für die Performance:

vers=3: Nutzt NFSv3 (meist stabiler als v4 für Virtualisierung)
soft: Wichtig! Limitiert Retry-Versuche auf 3, verhindert hängende VMs bei NFS-Problemen

Die Storage-Konfiguration in /etc/pve/storage.cfg

Nach dem Befehl steht automatisch folgendes in der Datei:

nfs: iso-templates
    path /mnt/pve/iso-templates
    server 10.0.0.10
    export /space/iso-templates
    options vers=3,soft
    content iso,vztmpl

path /mnt/pve/iso-templates: Das ist der lokale Mount-Point auf jedem Proxmox-Node. Proxmox erstellt das Verzeichnis automatisch und mountet den NFS-Share dort.

Erweiterte NFS-Konfigurationen

Performance-optimierte Einstellungen

# Für VM-Images (höhere Performance erforderlich)
pvesm add nfs vm-storage \
  --server 10.0.0.10 \
  --export /space/vm-storage \
  --content images,rootdir \
  --options vers=3,hard,intr,rsize=32768,wsize=32768,tcp

Die Mount-Optionen erklärt:

hard: NFS-Requests werden unendlich wiederholt (für kritische Daten)
intr: Prozesse können mit Ctrl+C unterbrochen werden
rsize/wsize=32768: 32KB Blocks für bessere Performance
tcp: TCP statt UDP (zuverlässiger für VMs)

Backup-Storage konfigurieren

# Dedicated Backup-Storage
pvesm add nfs backup-nfs \
  --server backup.internal.lan \
  --export /backup/proxmox \
  --content backup \
  --options vers=4,soft,bg \
  --maxfiles 3

Backup-spezifische Optionen:

vers=4: NFSv4 für bessere Sicherheit und Performance
bg: Background-Mount falls Server nicht verfügbar
maxfiles 3: Maximal 3 Backup-Files pro VM (deprecated, aber funktional)

NFS Storage-Features verstehen

Snapshots und Clones mit qcow2

Da NFS selbst keine Hardware-Snapshots unterstützt, nutzt Proxmox das qcow2-Format für diese Features:

# VM mit qcow2 auf NFS erstellen
qm set 100 --scsi0 nfs-storage:vm-100-disk-0.qcow2

# Snapshot erstellen (intern qcow2-Snapshot)
qm snapshot 100 before-update

# Clone erstellen (qcow2-backed)
qm clone 100 101 --name cloned-vm

Der Unterschied zu LVM-Thin:

LVM-Thin: Hardware-Level Snapshots (sehr schnell)
NFS + qcow2: Software-Level Snapshots (flexibler, aber langsamer)

Migration und Live-Migration

Das ist der Hauptvorteil von NFS in Clustern:

# Live-Migration zwischen Nodes (ohne Storage-Transfer!)
qm migrate 100 node2 --online

# Warum geht dass so schnell? 
# - VM-Daten liegen auf NFS (für alle Nodes zugänglich)
# - Nur RAM-Inhalt wird übertragen
# - Keine Disk-Kopierung nötig

Praktische Anwendungsszenarien

Szenario 1: Homelab mit Synology NAS

# Synology NFS aktivieren und Export erstellen
# Über DSM: Systemsteuerung → Dateidienste → NFS → Aktivieren

# In Proxmox konfigurieren
pvesm add nfs synology-storage \
  --server 192.168.1.200 \
  --export /volume1/proxmox \
  --content images,backup,iso \
  --options vers=3,hard,intr

Szenario 2: Dedizierter NFS-Server (Ubuntu/Debian)

NFS-Server setup:

# Auf dem NFS-Server
apt install nfs-kernel-server

# Exports konfigurieren
cat >> /etc/exports << 'EOF'
/exports/proxmox-vms    192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)
/exports/proxmox-backup 192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)
/exports/proxmox-iso    192.168.1.0/24(ro,sync,no_subtree_check)
EOF

exportfs -ra
systemctl enable nfs-server

In Proxmox nutzen:

# VM Storage
pvesm add nfs nfs-vms \
  --server 192.168.1.100 \
  --export /exports/proxmox-vms \
  --content images,rootdir

# Backup Storage  
pvesm add nfs nfs-backup \
  --server 192.168.1.100 \
  --export /exports/proxmox-backup \
  --content backup

# ISO Storage (read-only)
pvesm add nfs nfs-iso \
  --server 192.168.1.100 \
  --export /exports/proxmox-iso \
  --content iso,vztmpl

Troubleshooting und Monitoring

Häufige NFS-Probleme

Problem: „Connection refused“ oder „No route to host“

# 1. Netzwerk-Konnektivität testen
ping 10.0.0.10

# 2. NFS-Service prüfen  
rpcinfo -p 10.0.0.10

# 3. Firewall checken (Server-seitig)
# NFS benötigt mehrere Ports:
# - 111 (rpcbind)
# - 2049 (nfs)  
# - Dynamische Ports für rpc.statd, rpc.mountd

Problem: „Stale file handle“

# Mount neu durchführen
umount /mnt/pve/nfs-storage
pvesm set nfs-storage --disable 1
pvesm set nfs-storage --disable 0

# Oder Storage komplett neu hinzufügen
pvesm remove nfs-storage
pvesm add nfs nfs-storage --server ... --export ...

Problem: Schlechte Performance

# NFS-Mount-Optionen optimieren
pvesm set nfs-storage --options vers=3,hard,intr,rsize=65536,wsize=65536,tcp

# Netzwerk-Performance testen
iperf3 -c nfs-server

# I/O-Performance testen  
dd if=/dev/zero of=/mnt/pve/nfs-storage/test bs=1M count=1000

NFS-Monitoring einrichten

# NFS-Status überwachen
cat > /usr/local/bin/nfs-health-check.sh << 'EOF'
#!/bin/bash
for storage in $(pvesm status | grep nfs | awk '{print $1}'); do
    if ! pvesm status --storage $storage >/dev/null 2>&1; then
        echo "NFS Storage $storage offline!" | \
            logger -t nfs-monitor
        # Mail/Alert senden
    fi
done
EOF

# Alle 2 Minuten prüfen
echo "*/2 * * * * root /usr/local/bin/nfs-health-check.sh" >> /etc/crontab

Best Practices für NFS in Proxmox

Netzwerk-Design

# Dediziertes Storage-Netzwerk verwenden
# Management: 192.168.1.x  
# Storage: 10.0.0.x (Gigabit oder besser)

auto vmbr1
iface vmbr1 inet static
    address 10.0.0.11/24
    bridge-ports eth1
    # Kein Gateway - nur Storage-Traffic

Mount-Optionen je nach Anwendung

# Für Read-Only Content (ISOs, Templates)
--options vers=3,ro,soft,intr

# Für VM-Images (kritisch)  
--options vers=3,hard,intr,tcp,rsize=32768,wsize=32768

# Für Backups (kann unterbrochen werden)
--options vers=3,soft,bg,intr

Redundanz und Hochverfügbarkeit

# NFS-Server mit Failover
# Primary: 10.0.0.10
# Secondary: 10.0.0.11

# Heartbeat-Script für automatisches Failover
cat > /usr/local/bin/nfs-failover.sh << 'EOF'
#!/bin/bash
PRIMARY="10.0.0.10"
SECONDARY="10.0.0.11"

if ! ping -c 3 $PRIMARY >/dev/null 2>&1; then
    # Primary offline - auf Secondary umschalten
    pvesm set nfs-storage --server $SECONDARY
    logger "NFS failover to secondary server"
fi
EOF

NFS ist besonders gut geeignet, wenn ihr eine einfache, aber dennoch professionelle Shared-Storage-Lösung für euren Proxmox-Cluster sucht. Die Konfiguration ist unkompliziert, die Performance für die meisten Anwendungsfälle völlig ausreichend und die Wartung minimal!

Nur der Vollständigkeit halber möchte ich auch noch fix auf die Windows Variante von NFS eingehen. Die hört auf den Namen CIFS und verhält sich im großen und ganzen unter Proxmox gleich: Der wesentliche Unterschied zwischen NFS und CIFS (heute meist als SMB bezeichnet) liegt in ihrer Entwicklungsgeschichte und Zielplattform. NFS wurde für Unix-basierte Systeme wie Linux entwickelt, während CIFS/SMB ursprünglich für Windows-Systeme konzipiert war.

NFS (Network File System)

Ursprung: Entwickelt von Sun Microsystems für Unix-Systeme.
Funktionsweise: Ermöglicht Clients den Zugriff auf Dateien und Verzeichnisse, die auf einem entfernten Server gespeichert sind, als wären sie lokal. Der Zugriff erfolgt über einen „Mount“-Prozess.
Performance: Oft als performanter für Unix/Linux-Umgebungen angesehen, da es dort nativ integriert ist und weniger Overhead hat.
Einschränkung: Kann ressourcenintensiv sein, wenn es in Nicht-Linux-Umgebungen verwendet wird, da oft zusätzliche Software benötigt wird.
Aktueller Status: NFSv4 ist die aktuelle Version und bietet verbesserte Sicherheits- und Performance-Funktionen. Es wird aktiv weiterentwickelt.

CIFS (Common Internet File System) / SMB (Server Message Block)

Aktueller Status: CIFS ist technisch veraltet. Das aktuelle Protokoll heißt SMB (Server Message Block), das in ständiger Entwicklung ist und in modernen Windows-Systemen als Standard für die Dateifreigabe dient. Mit Samba kann es aber auch in Unix/Linux-Umgebungen genutzt werden, um Kompatibilität zu Windows-Systemen herzustellen.

Ursprung: CIFS ist eine spezielle Version des SMB-Protokolls von Microsoft. Im modernen Kontext werden die Begriffe oft synonym verwendet oder CIFS bezeichnet die veraltete SMB-Version 1.0.

Funktionsweise: Clients können über das Netzwerk auf Dateien, Drucker und andere Ressourcen eines Servers zugreifen. CIFS/SMB ist ein zustandsbehaftetes Protokoll, das bedeutet, der Server verfolgt die Verbindungen und den Zustand der geöffneten Dateien.

Performance: Kann in WAN-Verbindungen langsamer sein als NFS (insbesondere ältere Versionen), aber moderne SMB-Versionen (SMB2, SMB3) haben deutliche Leistungsverbesserungen.

Einschränkung: CIFS/SMB1 gilt als unsicher und wird in modernen Systemen standardmäßig deaktiviert oder nicht mehr verwendet.

Wenn wir gerade schon dabei sind, schauen wir uns den Rest doch auch gleich nochmal genauer an. Die offizielle Dokumentation zeigt, wie Proxmox die Speichertypen ZFS, BTRFS und CEPH als Speicher-Backends nutzt. Dabei gibt es klare Empfehlungen für verschiedene Anwendungsfälle.

Proxmox und ZFS

Proxmox sieht ZFS als eine leistungsstarke und zuverlässige Lösung für Single-Host-Speicher oder kleine, replizierte Setups.

Implementierung in Proxmox: ZFS wird in Proxmox als ein integriertes Storage-Plugin genutzt. Ihr könnt direkt im Webinterface einen ZFS-Pool auf lokalen Festplatten erstellen. Proxmox nutzt die Copy-on-Write-Fähigkeit von ZFS, um sehr schnelle Snapshots und Klone von VMs zu erstellen.

Datenintegrität: Die Prüfsummen (Checksums) von ZFS schützen eure VM-Daten vor stiller Datenkorruption, was für kritische Workloads essenziell ist.

Effiziente Snapshots: Snapshots sind sehr schnell und verbrauchen kaum Speicherplatz, was für Backup-Strategien + Testing/Staging extrem nützlich ist.

RAID-Z: Proxmox unterstützt die Erstellung von ZFS-RAID-Konfigurationen (RAID-Z1, RAID-Z2, RAID-Z3) über das Webinterface, was die Datensicherheit erhöht.

Wann zu verwenden: ZFS ist die bevorzugte Wahl für einen Einzelserver, der hohe Zuverlässigkeit, Datenintegrität und einfache Snapshot-Funktionen benötigt. Die offizielle Dokumentation empfiehlt es auch für Cluster, wenn man ZFS über die Proxmox-eigene Replication Engine synchronisiert.

Proxmox und BTRFS

BTRFS wird in der Proxmox-Dokumentation als eine moderne, flexible Alternative zu ZFS beschrieben, die ebenfalls Copy-on-Write-Funktionen bietet. Es ist ebenfalls für den lokalen Speicher auf einem Host gedacht.

Implementierung in Proxmox: Ähnlich wie ZFS kann BTRFS direkt im Proxmox-Webinterface als Dateisystem und Speichertyp konfiguriert werden. Proxmox nutzt die Subvolumes- und Snapshot-Funktionen von BTRFS.

Einfachheit: BTRFS wird oft als einfacher zu handhaben angesehen, insbesondere bei der Verwaltung von Subvolumes.

Integrierte RAID-Funktionen: BTRFS bietet eigene RAID-Level (RAID 0, 1, 10). Die Dokumentation erwähnt jedoch, dass RAID 5 und RAID 6 noch als experimentell gelten. Dort ist also definitiv Vorsicht geboten!

Balance: BTRFS bietet eine eingebaute Funktion namens „Balance“, die Daten zwischen den Festplatten verteilt und die Metadaten optimiert.

Wann zu verwenden: BTRFS ist eine gute Option, wenn Ihr die Flexibilität und die Funktionen eines modernen Dateisystems auf einem Einzelhost nutzen möchtet, aber die Ressourcenanforderungen von ZFS vermeiden wollt. Es ist eine solide Wahl für kleinere Umgebungen.

Proxmox und Ceph

Ceph ist in Proxmox die empfohlene Lösung für Cluster-Speicher. Es ist tief in die Proxmox-Infrastruktur integriert und ermöglicht es, einen hochverfügbaren, verteilten Speicherpool über mehrere Hosts hinweg zu erstellen.

Wann zu verwenden: Ceph ist die ideale Lösung für größere Cluster (drei oder mehr Nodes). Es ermöglicht euch, einen zentralen, hochverfügbaren Speicherpool für alle VMs im Cluster zu erstellen, der keine Single-Point-of-Failure hat. Auch die Proxmox-Dokumentation hebt deutlich hervor, dass Ceph die beste Wahl für Shared Storage in einem Proxmox-HA-Cluster ist.

Implementierung in Proxmox: Proxmox bietet eine native Ceph-Integration über das Webinterface, mit der Ihr einen Ceph-Cluster auf eurem Proxmox-Hosts einrichten und verwalten können. Jeder Host kann als Ceph-Node (OSD, Monitor, Manager) dienen.

Vorteile:

Hohe Skalierbarkeit: Es können einfach weitere Hosts zum Cluster hinzu gefügt werden, um die Kapazität und Leistung zu erhöhen.

Hochverfügbarkeit: Ceph repliziert Daten über die Cluster-Nodes. Fällt ein Host aus, bleibt der Speicher weiterhin verfügbar.

Unified Storage: Über Ceph könnt Ihr Block-Devices (RBDs) für VMs, Objekt-Speicher (RADOS Gateway) und Dateisysteme (CephFS) bereitstellen.

Die verschiedene Storage-Backends im Detail

1. Directory Storage (einfach aber flexibel)

# Lokales Verzeichnis als Storage
pvesm add dir backup-local \
  --path /backup \
  --content backup,iso,template \
  --shared 0

# NFS-Share als Storage
pvesm add nfs shared-storage \
  --server 192.168.1.100 \
  --export /exports/proxmox \
  --content images,template,backup \
  --options vers=3

Vorteile:

Einfach zu verstehen und verwalten
Flexibel für verschiedene Inhalte
Snapshots via Dateisystem (bei Nutzung von ZFS/BTRFS)

Nachteile:

Langsamere Snapshots bei großen Images
Weniger effiziente Speichernutzung

2. ZFS Storage (Enterprise-Features)

# ZFS Pool erstellen
zpool create -f tank \
  raidz2 /dev/sdb /dev/sdc /dev/sdd /dev/sde \
  cache /dev/nvme0n1p1 \
  log /dev/nvme0n1p2

# ZFS-Optimierungen
zfs set compression=lz4 tank
zfs set atime=off tank
zfs set xattr=sa tank
zfs set relatime=on tank

# Als Proxmox Storage hinzufügen
pvesm add zfspool zfs-storage \
  --pool tank \
  --content images,rootdir \
  --sparse 1

ZFS-Vorteile:

Integrierte Snapshots und Replication
Compression und Deduplication
Sehr robust durch Checksums
Cache und L2ARC für Performance

3. Ceph Storage (für Cluster)

# Ceph OSD erstellen
ceph-deploy osd create --data /dev/sdb proxmox1
ceph-deploy osd create --data /dev/sdc proxmox2
ceph-deploy osd create --data /dev/sdd proxmox3

# Pool für VMs erstellen
ceph osd pool create vm-storage 128 128
ceph osd pool application enable vm-storage rbd

# In Proxmox integrieren
pvesm add ceph ceph-storage \
  --pool vm-storage \
  --content images \
  --krbd 0

ZFS und BTRFS: Die „Scale-Up“-Ansätze (Einzelserver)

ZFS (Zettabyte File System) ist ein ausgereiftes Dateisystem und Volume-Manager, das vor allem für seine starke Datenintegrität bekannt ist. Es wurde für den Einsatz auf einem einzelnen, leistungsstarken Server konzipiert.

Vorteile: Überragende Datenintegrität dank Copy-on-Write und Prüfsummen. Flexible RAID-Varianten (RAID-Z). Sehr zuverlässig und stabil.
Nachteile: Kann ressourcenhungrig sein (RAM). Skaliert primär nur vertikal. Manchmal komplex in der Handhabung.
Anwendungsbereich: Single-Host-Systeme, Workstations, kleine bis mittlere Server, NAS-Systeme.

BTRFS (B-Tree File System) ist ein moderner „Copy-on-Write“-Dateisystem-Ansatz für Linux, der viele Funktionen von ZFS nachbildet, aber oft als flexibler und einfacher in der Verwaltung gilt.

Vorteile: Integrierte Volume-Management-Funktionen. Einfache Handhabung von Subvolumes und Snapshots. Inkrementelle Backups. Eingebautes RAID.
Nachteile: Die RAID5/6-Implementierung wird teils noch als experimentell betrachtet und ist nicht so robust wie bei ZFS.
Anwendungsbereich: Linux-Systeme, bei denen man die Vorteile von Snapshots und Datenintegrität ohne den Ressourcen-Overhead von ZFS nutzen möchte. Ideal für Heimserver und Proxmox-Hosts, die lokal Daten speichern.

Ceph: Der „Scale-Out“-Ansatz (Cluster)

Ceph ist keine Alternative zu ZFS oder BTRFS auf einem einzelnen Server. Es ist eine software-definierte Speicherlösung für große, verteilte Cluster. Sein Hauptziel ist es, einen zentralen Speicherpool über viele Server hinweg bereitzustellen.

Vorteile: Extrem hohe Skalierbarkeit (horizontal). Hohe Ausfallsicherheit durch Selbstheilung und verteilte Daten. Bietet Block-, Objekt- und Dateispeicher.
Nachteile: Sehr komplex in der Einrichtung und Verwaltung. Hohe Anforderungen an die Infrastruktur (mindestens 3 Knoten empfohlen).
Anwendungsbereich: Große Cloud-Umgebungen, Virtualisierungs-Cluster, sehr große Datenarchive.

Zusammenfassung und Empfehlung

Merkmal	ZFS	BTRFS	Ceph
Konzept	Scale-Up (Einzelserver)	Scale-Up (Einzelserver)	Scale-Out (Cluster)
Zielgruppe	Zuverlässigkeit, Datenintegrität	Flexibilität, Einfachheit (Linux)	Skalierbarkeit, Hochverfügbarkeit
Skalierung	Vertikal (mehr Platten in einem Server)	Vertikal (mehr Platten in einem Server)	Horizontal (mehr Server im Cluster)
Anwendungsgröße	Klein bis mittel	Klein bis mittel	Mittel bis groß (ab 3+ Knoten)
Hauptvorteil	Industriestandard für Datenintegrität	Flexibel und „native“ in Linux	Maximale Ausfallsicherheit & Skalierbarkeit
Hauptnachteil	Hoher RAM-Bedarf	RAID5/6 noch nicht komplett ausgereift	Hohe Komplexität und Infrastrukturanforderungen

Zusammenfassend kann man daher folgendes sagen:

Wahl für einen einzelnen Proxmox-Host: ZFS oder BTRFS sind die richtige Wahl. Beide bieten Snapshots und gute Datenintegrität. ZFS ist der Goldstandard für Zuverlässigkeit, BTRFS ist aber oft einfacher und definitiv ressourcenschonender.

Wahl für einen Proxmox-Cluster: Ceph ist die beste Wahl, wenn Ihr mehrere Hosts habt und einen zentralen, hochverfügbaren Speicherpool aufbauen möchtet, der auch langfristig mit eurem Cluster wachsen kann.

Performance-Optimierung im Detail

SSD-Optimierungen

TRIM/Discard aktivieren

# Für einzelne VM
qm set 100 --scsi0 local-lvm:vm-100-disk-0,discard=on,ssd=1

# Global für alle neuen VMs (in Storage-Konfiguration)
pvesm set local-lvm --content images --discard-support 1

# System-Level TRIM (wöchentlich)
systemctl enable fstrim.timer

SSD-spezifische Scheduler

# Optimal für SSDs
echo mq-deadline > /sys/block/sda/queue/scheduler

# Permanent via udev
cat > /etc/udev/rules.d/60-ssd-scheduler.rules << 'EOF'
ACTION=="add|change", KERNEL=="sd[a-z]|nvme[0-9]n[0-9]", \
ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="mq-deadline"
EOF

I/O-Thread und Cache-Optimierung

# I/O-Thread für bessere Parallelisierung
qm set 100 --scsi0 local-lvm:vm-100-disk-0,iothread=1
qm set 100 --scsihw virtio-scsi-single

# Cache-Modi je nach Anwendung
# writethrough: Sicher, aber langsamer
qm set 100 --scsi0 local-lvm:vm-100-disk-0,cache=writethrough

# writeback: Schneller, aber Datenverlust-Risiko bei Stromausfall  
qm set 100 --scsi0 local-lvm:vm-100-disk-0,cache=writeback

# none: Für shared Storage (Cluster)
qm set 100 --scsi0 ceph-storage:vm-100-disk-0,cache=none

Multi-Path I/O für Enterprise Storage

# Multipath installieren und konfigurieren
apt install multipath-tools

cat > /etc/multipath.conf << 'EOF'
defaults {
    user_friendly_names yes
    find_multipaths yes
}

multipaths {
    multipath {
        wwid 36001405d27e5d898dd34a9f98a9a8f55
        alias shared-storage-lun1
    }
}
EOF

systemctl enable multipathd
systemctl start multipathd

Storage-Layout Best Practices im TL:DR

Empfohlenes Layout für verschiedene Szenarien

Homelab (1 oder 2 Server)

# SSD 1: System + lokale VMs
/dev/sda1: EFI boot (512MB)
/dev/sda2: root (50GB) 
/dev/sda3: LVM-Thin Pool (rest)

# HDD 1: Backups + ISO Storage
/dev/sdb1: /backup (komplette Disk)

# Konfiguration:
# local-lvm: images,rootdir (SSD)
# backup-local: backup,iso (HDD)

Kleine Produktionsumgebung (3+ Server)

# Pro Server:
# NVMe 1: System (RAID1 Mirror)
/dev/nvme0n1: Proxmox System

# NVMe 2: Lokale VMs (Hot Data)  
/dev/nvme1n1: Local LVM-Thin Pool

# SAS/SATA: Shared Storage via Ceph
/dev/sd[a-c]: Ceph OSDs

# Externes NAS: Backups
nfs://backup.internal.lan/proxmox

Enterprise (viele Server, Clusterbetrieb)

# Dedicated Storage:
# - SAN (iSCSI/FC) für VM Images
# - NFS für Templates/ISOs  
# - Dedicated Backup-System
# - Separate Ceph-Cluster

# Pro Proxmox-Node nur System-SSD
/dev/sda: Proxmox System (RAID1)
# Alles andere über Netzwerk

Storage-Tiering implementieren

# Tier 1: NVMe für kritische VMs
pvesm add lvmthin nvme-tier1 \
  --vgname nvme-vg \
  --thinpool nvme-pool \
  --content images

# Tier 2: SATA-SSD für Standard-VMs  
pvesm add lvmthin ssd-tier2 \
  --vgname ssd-vg \
  --thinpool ssd-pool \
  --content images,rootdir

# Tier 3: HDD für Archive/Backup
pvesm add dir hdd-tier3 \
  --path /archive \
  --content backup,template

Best Practices aus der Proxmox-Dokumentation

Content Types richtig zuweisen

Verschiedene Storage-Typen unterstützen verschiedene Content-Types Storage:

# Spezialisierte Storage für verschiedene Zwecke
pvesm add lvmthin vm-storage --vgname pve-fast --thinpool fast --content images
pvesm add lvmthin ct-storage --vgname pve-bulk --thinpool bulk --content rootdir  
pvesm add dir iso-storage --path /var/lib/vz/template --content iso,vztmpl

Storage nicht „aliasing“

Es ist problematisch, mehrere Storage-Konfigurationen auf den gleichen Storage zu zeigen Storage:

# FALSCH - Beide zeigen auf gleichen Thin Pool
pvesm add lvmthin storage1 --vgname pve --thinpool data --content images
pvesm add lvmthin storage2 --vgname pve --thinpool data --content rootdir

# RICHTIG - Ein Storage für beide Content-Types
pvesm add lvmthin local-lvm --vgname pve --thinpool data --content images,rootdir

Volume Ownership verstehen

Jedes Volume gehört einer VM oder einem Container Storage:

# Volume ID Format verstehen:
# local-lvm:vm-100-disk-0
#    ^         ^      ^
#    |         |      └── Disk-Nummer  
#    |         └────────── VM-ID
#    └─────────────────── Storage-ID

# Volume-Pfad ermitteln
pvesm path local-lvm:vm-100-disk-0
# /dev/pve-data/vm-100-disk-0

Performance-Tuning nach Proxmox-Standards

I/O-Scheduler für LVM-Thin optimieren

# Für SSDs unter LVM-Thin
echo mq-deadline > /sys/block/sda/queue/scheduler

# Queue-Depth anpassen
echo 32 > /sys/block/sda/queue/nr_requests

# Read-ahead für sequenzielle Workloads
blockdev --setra 4096 /dev/sda

VM-Konfiguration für optimale Performance

# Beste Performance-Einstellungen für LVM-Thin
qm set 100 --scsi0 local-lvm:vm-100-disk-0,iothread=1,discard=on,ssd=1

# Parameter erklärt:
# iothread=1: Separate I/O-Threads für bessere Parallelisierung
# discard=on: TRIM-Support für SSD-Optimierung  
# ssd=1: Teilt der VM mit, dass es eine SSD ist

Wartung und Monitoring

Thin Pool Health-Check

# Detaillierte Pool-Informationen
dmsetup status | grep thin

# Thin Pool reparieren (wenn corrupted)
lvconvert --repair pve-data/data

# Thin Pool Chunk-Usage anzeigen
thin_dump /dev/pve-data/data_tmeta | less

Regelmäßige Wartungsaufgaben

# Wöchentliche Wartung

cat > /etc/cron.weekly/lvm-maintenance << 'EOF'
#!/bin/bash
# Thin Pool defragmentieren
fstrim -av

# LVM-Metadaten sichern  
vgcfgbackup

# Unused Logical Volumes aufräumen
lvremove $(lvs --noheadings -o lv_path,lv_attr | \
          awk '$2 ~ /^V.*a.*z/ {print $1}' | \
          head -5)
EOF

Dieser Code-Abschnitt ist das Fundament für hochperformanten, flexiblen Storage in Proxmox

Storage-Migration und Wartung

VMs zwischen Storages migrieren

# Offline-Migration (VM ausgeschaltet)
qm migrate 100 node2 --targetstorage new-storage

# Online-Migration (VM läuft weiter)  
qm migrate 100 node2 --online --targetstorage new-storage

# Nur Storage ändern (same Node)
qm move-disk 100 scsi0 new-storage --delete

Storage-Wartung ohne Downtime

# 1. VMs von Storage weg migrieren
for vm in $(qm list | grep running | awk '{print $1}'); do
    qm migrate $vm node2 --targetstorage backup-storage --online
done

# 2. Storage-Wartung durchführen
# - Festplatten tauschen
# - RAID rebuilden  
# - etc.

# 3. VMs zurück migrieren
for vm in $(qm list | grep running | awk '{print $1}'); do  
    qm migrate $vm node1 --targetstorage main-storage --online
done

Monitoring und Troubleshooting

Storage-Performance überwachen

# I/O-Statistiken live
iostat -x 1

# Per-VM I/O Monitoring
iotop -ao

# Storage-latency messen
ioping /var/lib/vz/

Häufige Storage-Probleme lösen

Problem: „No space left on device“

# 1. Speicherverbrauch analysieren
df -h
lvs --all
du -sh /var/lib/vz/*

# 2. Thin Pool erweitern
lvextend -L +100G /dev/pve/data

# 3. Unused Blocks freigeben
fstrim -av

Problem: Schlechte I/O-Performance

# 1. Scheduler prüfen
cat /sys/block/sda/queue/scheduler

# 2. I/O-Queue-Depth optimieren
echo 32 > /sys/block/sda/queue/nr_requests

# 3. VM-Konfiguration checken  
qm config 100 | grep scsi
# iothread=1, cache=none/writeback je nach Setup

Problem: Storage nicht verfügbar

# 1. Storage-Status prüfen
pvesm status

# 2. Mount-Points checken
mount | grep /var/lib/vz

# 3. Netzwerk-Storage testen
ping storage-server
showmount -e storage-server

# 4. Storage neu aktivieren
pvesm set storage-name --disable 0

Storage ist das Fundament deiner Proxmox-Installation – investiere hier die meiste Zeit in Planung und Setup! Das zahlt sich später im Kaffee-Konsum und oder Verbrauch von Kopfschmerztabletten defintiv wieder aus. 😉

Abschluss und weiterführende Ressourcen

Proxmox ist ein mächtiges Werkzeug, aber mit großer Macht kommt auch große Verantwortung. (zwinker) Die hier gezeigten Best Practices sind das Ergebnis aus Erfahrung in der Praxis. Beginnt mit den Grundlagen und arbeitet euch nach und nach zu den erweiterten Features vor.

Eure nächsten Schritte:

Testing/Staging Umgebung aufbauen: Testet alle Konfigurationen erst in einer separaten Umgebung
Monitoring implementieren: Überwacht euer System von Anfang an
Backup-Strategie testen: Macht regelmäßige Restore-Tests
Community beitreten: Das Proxmox-Forum ist sehr hilfsreich

Denkt also daran: Nehmt euch die Zeit, die Grundlagen zu verstehen, bevor ihr zu komplexeren Setups übergeht. Der Proxmox-Admin-Guide als Webseite den ich im Artikel mehrfach als Referenz verlinkt habe ist auch Gold wert. Schaut euch ruhig im Forum um, wenn Ihr Frage habt. Ansonsten gibt es auch für den Einstieg noch einen Youtube-Channel.

Die restlichen Teile dieser Artikelserie habe ich hier auch noch einmal für euch verlinkt: Teil 1: Netzwerk | Teil 2: Storage | Teil 3: Backup | Teil 4: Sicherheit | Teil 5: Performance

Proxmox Best Practice Teil 2 – Storage: LVM-Thin und noch viel mehr