VM-Storage, Snapshots und Kapazität

Eine virtuelle 500-GiB-Disk belegt nicht automatisch 500 GiB

Eine VM sieht ein Blockgerät mit einer virtuellen Größe. Der Host kann dafür eine Image-Datei, ein Logical Volume, ein Netzwerk-Volume oder ein anderes Backend bereitstellen. Dieses Backend kann vollständig vorab belegt sein oder Blöcke erst beim Schreiben anfordern. Darüber liegen möglicherweise Snapshots, darunter ein gemeinsam genutzter Pool. Deshalb sind „500 GiB Disk“, „180 GiB im Gast belegt“ und „95 GiB physisch im Pool verbraucht“ drei verschiedene Aussagen. Storagebetrieb beginnt mit vier getrennten Fragen: Was sieht der Gast? Welche Kette liest und beschreibt der Hypervisor? Was hat das Backend tatsächlich zugeteilt? Welche gemeinsame Reserve bleibt? Wer nur eine Ebene betrachtet, kann freien Platz melden, während die nächste Schreibanforderung an einer anderen Grenze scheitert. Das gilt ebenso für Leistung. Eine Anwendung meldet hohe Antwortzeit, der Gast sieht I/O-Wartezeit, der Hypervisor zählt Schreiboperationen und das Backend zeigt eine Queue. Erst Identität und Zeitfenster verbinden diese Signale. Ein hoher Einzelwert ist noch keine Ursache. Dieses Modul verwendet QEMU/Libvirt und LVM Thin als konkrete, überprüfbare Beispiele. Die Begriffe übertragen sich auf andere Plattformen, ihre Kommandos und Snapshotsemantik jedoch nicht blind. Dokumentiere daher Format, Backend und Plattformverfahren je Disk statt nur den Produktnamen des Datastores.

Vier Schichten liefern vier verschiedene Wahrheiten

Gast und Anwendung

Dateisystembelegung, freie Blöcke, Flushverhalten und anwendungsseitige Latenz innerhalb der VM.

Virtuelles Blockgerät

Zielname, virtuelle Größe, Cache- und I/O-Modell sowie die vom Gast sichtbare Geräteidentität.

Image oder Volume

Format, tatsächlich allozierte Blöcke, Backing-Datei, Overlay und Snapshotbeziehungen.

Pool und Medium

Physische Daten- und Metadatenbelegung, Redundanz, Latenz, Durchsatz und gemeinsame Reserve.

Die Schichten sind gekoppelt, aber nicht austauschbar. df -h im Gast berichtet über das dort eingehängte Dateisystem. Es kennt weder die physische Belegung eines Thin Pools noch Blöcke, die ein Snapshot festhält. virsh domblklist app-01 --details ordnet einer Domain ihre Blockziele und Quellen zu; mit --inactive liest es die Konfiguration für den nächsten Start statt die Geräte der laufenden Domain. virsh domblkinfo app-01 vda --human liefert Größeninformationen zum Domain-Blockgerät. ``bash virsh domblklist app-01 --details virsh domblkinfo app-01 vda --human ` Halte in einer Diagnose nicht nur den Befehl fest, sondern auch Domain, Verbindung, Blockziel, Quelle und Zeitpunkt. vda ist innerhalb einer Domain eindeutig, aber kein flottenweit eindeutiger Datenträgername. Eine Datei unter /var/lib/libvirt/images/` kann wiederum nur die oberste Schicht einer längeren Backing-Kette sein. Ein belastbares Inventar verbindet diese Ebenen in einer Richtung: Dienst und VM → virtuelles Ziel → aktive Quelle → Backing-Kette oder Volume → Pool → physische Fehlerdomäne. Die Gegenrichtung ist für den Blast Radius nötig: Welche Dienste hängen an genau diesem Pool oder Image? Beide Abfragen müssen vor Konsolidierung, Konvertierung oder Kapazitätserweiterung reproduzierbar sein.

Virtuelle Größe, belegte Blöcke und Zusage getrennt messen

Bei Thin Provisioning werden physische Blöcke erst beim Schreiben zugeteilt. lvmthin(7) beschreibt ausdrücklich, dass die virtuelle Größe eines Thin LV größer als der physisch vorhandene Thin Pool sein kann. Das ist keine kostenlose Kapazität, sondern eine Wette darauf, dass nicht alle Zusagen gleichzeitig physisch werden. LVM Thin trennt Daten und Metadaten. Die Datenkomponente enthält die zugeteilten Nutzblöcke; die Metadatenkomponente verfolgt, welche Blöcke zu welchen Thin LVs und Snapshots gehören. Deshalb gehören data_percent und metadata_percent gemeinsam in die Überwachung: ``bash lvs -a -o name,attr,size,pool_lv,origin,data_percent,metadata_percent vg0 ` Eine niedrige Gastbelegung garantiert keinen niedrigen Poolverbrauch. Gelöschte Gastdateien können als physisch zugeteilte Blöcke bestehen bleiben. Snapshots können Blöcke weiter referenzieren. Umgekehrt kann eine große virtuelle Disk anfangs sehr wenig physische Kapazität belegen. Plane deshalb mindestens drei Werte: **virtuell zugesagt**, **physisch alloziert** und **für Ausfall, Wachstum und Wartung reserviert**. Für Image-Dateien zeigt qemu-img info --backing-chain` Format, virtuelle Größe und die ermittelte Backing-Kette. Führe Imagewerkzeuge nur nach dem für die Plattform dokumentierten Offline- oder Locking-Verfahren aus; eine laufend beschriebene Disk ist kein neutrales Analyseobjekt. Für eine aktive Libvirt-Domain sind deren Abfragen und Blockjob-Schnittstellen die erste Wahl. Ein Kapazitätsbericht ohne Snapshot- und Metadatenbezug unterschätzt das Risiko. Ein Bericht nur über die Summe virtueller Diskgrößen überschätzt dagegen den heutigen Verbrauch und kann trotzdem die Gleichzeitigkeit künftiger Schreiblast verfehlen. Die betriebliche Frage lautet nicht „Wie hoch ist die Überbuchung?“, sondern „Welche Schreib- und Änderungsraten können innerhalb der Reaktionszeit physisch werden?“

Allokationsverfahren kaufen unterschiedliche Eigenschaften

Sparse oder thin — Virtueller Adressraum wird vorab zugesagt, physische Blöcke werden erst bei Nutzung zugeteilt. Das spart Anfangskapazität, verlangt aber Poolüberwachung und einen wirksamen Erweiterungs- oder Entlastungspfad.

Vollständig alloziert oder thick — Die vorgesehene Kapazität wird beim Anlegen reserviert oder zugeteilt. Das reduziert das spätere Out-of-Space-Risiko dieser Disk, bindet aber Kapazität unabhängig von ihrer Gastnutzung.

QEMU unterstützt unter anderem raw und qcow2; qcow2 bringt Funktionen wie Backing-Dateien und Snapshots mit. Das Format allein sagt aber nicht, wie das darunterliegende Dateisystem oder Volume physisch alloziert. Eine sparse Raw-Datei auf einem Thin LV kann mehrere dynamische Schichten besitzen. Ebenso kann eine qcow2-Datei per Preallocation mehr Blöcke vorab belegen. Jede zusätzliche dynamische Schicht verschiebt die Grenze, die überwacht werden muss. Ein Gast kann trimmen, das Image kann Discard verarbeiten, das Hostdateisystem kann sparse Bereiche freigeben und ein Thin Pool kann Discards ignorieren, intern verarbeiten oder an das Gerät weiterreichen. Schon eine nicht unterstützte oder absichtlich deaktivierte Stufe unterbricht die erwartete Rückgabe. Allokation ist auch eine Leistungsentscheidung. lvmthin(7) weist darauf hin, dass On-Demand-Allokation Blöcke fragmentieren und gegenüber vollständig provisionierten LVs Leistung kosten kann. Das bedeutet nicht, dass Thick pauschal schneller ist. Entscheidend sind Workload, Medium, Cache, Queueing und Implementierung. Wähle das Verfahren aus Messung und Ausfallvertrag, nicht aus einem Etikett. Der Preis von Thin ist operative Disziplin: Frühwarnwerte, Wachstumsprognose, Metadatenkontrolle und getestete Reaktion. Der Preis von Thick ist gebundene Kapazität und geringere Konsolidierungsdichte. Ein Standard kann beides nach Workloadklasse vorsehen, solange die Entscheidung im Inventar sichtbar bleibt.

Snapshots erzeugen eine Abhängigkeitskette, kein unabhängiges Backup

Ein Copy-on-Write-Snapshot teilt zunächst Blöcke mit seinem Ursprung. Neue Schreibvorgänge erzeugen die Abweichung. Dadurch ist die Erstellung schnell und anfangs klein; Wachstum und Abhängigkeit folgen während der Nutzung. Das Snapshotobjekt braucht Ursprung, Pool und Metadaten weiterhin. Ein Fehler derselben Storagegrenze kann beide Zustände treffen. Bei einer QEMU-Backing-Kette liest die aktive Schicht unveränderte Blöcke aus einer unteren Datei und hält neue Blöcke oben. Je länger und schreibaktiver die Kette, desto mehr Beziehungen müssen Diagnose, Migration und Konsolidierung korrekt behandeln. virsh blockcommit verkürzt eine Backing-Kette, indem Änderungen aus oberen Schichten in Backing Images geschrieben werden. Die Dokumentation warnt, dass beteiligte Dateien während des Commit ungültig werden können; ein Active Commit besitzt außerdem eine Kopier- und eine Pivot- beziehungsweise Keep-Overlay-Phase. Das ist ein kontrollierter Blockjob, kein Dateiaufräumen. Hyper-V unterscheidet Standard und Production Checkpoints. Ein Standard Checkpoint nimmt VM- und Arbeitsspeicherzustand auf und kann bei replizierenden Systemen Datenkonsistenzprobleme verursachen. Ein Production Checkpoint nutzt unter Windows VSS beziehungsweise unter Linux einen Dateisystem-Freeze und nimmt keinen Arbeitsspeicherzustand auf. Microsoft beschreibt Production Checkpoints als Standardauswahl, aber auch sie ersetzen kein unabhängig geschütztes Anwendungsbackup. Beim Löschen eines Hyper-V-Checkpoints werden .avhdx und .vhdx zusammengeführt. Die sichtbare Löschaktion kann daher I/O und Zeit benötigen. Dasselbe Grundprinzip gilt plattformübergreifend: Snapshot löschen bedeutet oft Datenbeziehungen konsolidieren, nicht lediglich einen kleinen Metadatensatz entfernen. Prüfe freie Reserve, Änderungsrate, erwartete Laufzeit, Abbruchsemantik und Nachweis der aktiven Kette vor dem Start.

Kapazitätssteuerung beginnt vor dem Alarm

Ein sinnvoller Frühwarnwert entsteht aus Reaktionszeit und Änderungsrate. Wenn ein Pool unter Spitzenlast 300 GiB pro Stunde wachsen kann und eine Erweiterung samt Freigabe zwei Stunden benötigt, sind 100 GiB Restkapazität kein früher Alarm. Addiere erwartetes Wachstum während der Reaktionszeit, Snapshot- oder Konsolidierungsbedarf, Recoveryreserve und einen Messpuffer. Die konkrete Schwelle ist daher pool- und betriebsabhängig. Überwache nicht nur einen Prozentwert. Benötigt werden aktueller physischer Verbrauch, Änderungsrate, größte bekannte Snapshot- oder Blockjoblast, Daten- und Metadatenstatus, fehlgeschlagene Erweiterungen sowie die Zeit bis zur Erschöpfung. LVM kann Thin Pools anhand konfigurierter Schwellwerte automatisch erweitern, sofern in der Volume Group freie Extents vorhanden sind. Autoextend erzeugt jedoch keine Kapazität; ein volles VG macht aus Automatik nur eine erfolglose Absicht. Für jede Warnstufe braucht es eine zulässige Reaktion. Früh kann ein Owner Wachstum prüfen oder nicht benötigte, freigegebene Snapshots konsolidieren. Später werden neue Provisionierungen und snapshotintensive Changes gestoppt. Im kritischen Bereich zählt kontrollierte Entlastung vor Komfort. Blindes Löschen, Konvertieren oder gleichzeitiges Migrieren vieler VMs kann genau die zusätzliche I/O- und Metadatenlast erzeugen, die den Pool endgültig erschöpft. Plane den Ausfallfall mit. Shared Storage muss während Hostwartung, Recovery und möglicher Rebuild-Last weiterarbeiten. Reserve, die nur den normalen Tagesbetrieb trägt, ist keine Recoveryreserve. Halte Ausnahmen mit Owner, Ablaufdatum und Kompensationsmaßnahme fest; sonst wird ein einmaliges Überbuchen zur unsichtbaren Baseline.

Löschen im Gast gibt physische Blöcke nicht automatisch zurück

Wenn ein Gast eine Datei löscht, markiert sein Dateisystem die Blöcke zunächst als intern wiederverwendbar. Damit darunterliegende Thin-Schichten davon erfahren, muss der Gast Discard beziehungsweise TRIM senden, das virtuelle Gerät muss die Information weitergeben und jedes Backend muss sie passend verarbeiten. fstrim kann ungenutzte Bereiche eingehängter Dateisysteme melden: ``bash fstrim --verbose /data ` Eine erfolgreiche Meldung belegt, dass der Gast einen Bereich verworfen hat. Sie beweist noch nicht, dass am Ende des physischen Pools derselbe Umfang frei wurde. LVM Thin kann Discards ignorieren, im Pool verarbeiten oder zusätzlich an das darunterliegende Gerät weiterreichen. Snapshots halten gemeinsam referenzierte Chunks weiter fest; lvmthin(7) nennt ausdrücklich, dass fstrim` keine Wirkung hat, wenn der Pool Discards ignoriert. Teste Reclaim deshalb Ende zu Ende und begrenzt. Erfasse vorher Gastbelegung, allozierte Diskblöcke, Pooldaten und Metadaten. Lösche Testdaten nach abgestimmtem Verfahren, trimme, warte auf asynchrone Verarbeitung und miss dieselben Ebenen erneut. Große Discard-Wellen können Leistung beeinflussen; plane sie wie andere Storagearbeit und beobachte Nachbarworkloads. Reclaim ist keine Notfallstrategie für einen beinahe vollen Pool. Er kann durch Snapshots, fehlende Weitergabe oder Backendregeln ausbleiben und benötigt Zeit. Die primäre Kontrolle bleibt ausreichende Reserve. Reclaim verbessert die langfristige Wiederverwendung, ersetzt aber weder Prognose noch einen verlässlichen Erweiterungspfad.

Storageleistung wird entlang des I/O-Pfads korreliert

Beginne mit der Dienstwirkung: Welche Transaktion, welcher Zeitraum und welche VM sind betroffen? Im Gast liefern Werkzeuge wie iostat -xz 1 Durchsatz, Latenz- und Queuehinweise aus Sicht des Betriebssystems. Auf der Libvirt-Ebene zählt domblkstat unter anderem Lese- und Schreiboperationen, Bytes, Fehler sowie je nach Hypervisor Gesamtzeiten für Read, Write und Flush. Die Felder sind kumulativ; für eine Rate oder mittlere Zeit brauchst du zwei Messpunkte und ein definiertes Intervall. ``bash virsh domblkstat app-01 vda --human iostat -xz 1 60 `` Beide Befehle messen unterschiedliche Grenzen. Gast-I/O kann durch Cache oder Zusammenfassung anders erscheinen als Backend-I/O. Eine hohe Queue im Gast kann an der virtuellen Disk, am Host, am Pool, am Netzwerkpfad oder am Medium entstehen. Umgekehrt kann ein Datastore hohe Last tragen, ohne dass dieser konkrete Dienst sein Ziel verfehlt. Korrelation braucht VM- und Diskidentität, synchronisierte Zeit und Vergleich mit einer gesunden Baseline. Prüfe gemeinsame Betroffenheit: Werden mehrere VMs desselben Pools im selben Fenster langsam, während ein anderer Pool unauffällig bleibt, liegt die nächste Evidenzgrenze beim gemeinsamen Storage. Betrifft es nur eine virtuelle Disk, vergleiche deren Blockstatistik, Snapshotkette, Gastqueue und Workload. CPU-, DNS- oder vCPU-Änderungen ohne diese Eingrenzung vergrößern den Diff und zerstören Vergleichbarkeit. Durchsatz und IOPS sind ohne Blockgröße und Latenz unvollständig. 1.000 Operationen mit 4 KiB und 1.000 Operationen mit 1 MiB belasten einen Pfad anders. p95- oder p99-Latenz zeigt Spitzen, die ein Mittelwert verbirgt. Queueing kann hohen Durchsatz erzeugen und zugleich ein Latenz-SLO verletzen. Bewerte daher Dienstziel, Operationsmix, Zeitverteilung und Sättigung gemeinsam.

Konsolidierung und Konvertierung sind Datenänderungen

Ein Image- oder Snapshotjob verändert die Storagebeziehung einer VM. Vorher werden aktive Quelle, vollständige Kette, virtuelle und allozierte Größe, freier Zielraum, aktuelle Schreibrate und Plattformzustand gesichert. Zusätzlich braucht der Dienst einen unabhängigen Recoveryweg; die zu konsolidierende Kette ist nicht ihr eigener Schutz. Bei blockcommit kann die Kopierphase im Hintergrund laufen. virsh blockjob app-01 vda --info dient zur Statusbeobachtung. Ein erfolgreicher Kopiervorgang allein schließt den Wechsel der aktiven Schicht nicht zwingend ab; Pivot, Keep-Overlay und Abbruch haben dokumentierte, unterschiedliche Folgen. Nutze daher ein hersteller- und versionspassendes Runbook statt aus Dateigrößen auf den Zustand zu schließen. ``bash virsh domblklist app-01 --details virsh blockjob app-01 vda --info `` Setze Bandbreitenbegrenzung und Abbruchsignal aus einer gemessenen Baseline. Ein ungedrosselter Job kann Nachbar-VMs beeinträchtigen; eine zu enge Begrenzung verlängert die Phase, in der zusätzliche Änderungen und Kapazitätsbedarf entstehen. Beobachte Dienstlatenz, Backendqueue, freien Raum und Jobfortschritt zusammen. Nach dem Job wird die aktive Quelle erneut über die Managementschnittstelle gelesen. Prüfe VM-I/O, Anwendungstransaktion, Fehlerzähler und erwartete Kettenlänge. Verwaiste Dateien werden erst nach Zuordnung und Freigabe behandelt. Dateinamen oder Änderungszeit allein beweisen weder Nutzung noch Entbehrlichkeit; eine vorschnelle Löschung kann die einzige noch referenzierte Basisschicht entfernen.

Arbeitsbeispiel: Ein gelöschter Snapshot lässt den Pool weiter wachsen

Ein Storage-Runbook endet bei der Dienstwirkung

• Scope: Dienst, Domain, Blockziel, aktive Quelle, Backing-Kette, Pool, Owner und Fehlerdomäne eindeutig festhalten.
• Baseline: virtuelle und physische Belegung, Daten- und Metadatenreserve, Änderungsrate, Latenz und laufende Jobs messen.
• Gate: Recoveryweg, Zielkapazität, Abbruchsignal, Bandbreitengrenze und zulässige Dienstwirkung vor dem Start freigeben.
• Ausführung: eine Storagebeziehung kontrolliert ändern und Job, Pool sowie Anwendung zeitgleich beobachten.
• Nachweis: aktive Quelle, erwartete Kette, Fehlerzähler, Poolreserve und repräsentative Transaktion bestätigen.
• Hygiene: temporäre Snapshots, Ausnahmen und Alarme erst nach Zuordnung und dokumentierter Freigabe bereinigen.

Die nächste Schicht ist die Verbindung zum Shared Storage. Multipathing, iSCSI, Fibre Channel und NFS bestimmen, wie ein Host sein Backend erreicht. Dieses Modul endet bewusst vorher: Es liefert den Disk-, Ketten-, Kapazitäts- und Leistungsnachweis, der an den Verbindungspfad übergeben wird. Ein Pfadstatus ohne diese Workloadsicht beweist keine ausreichende Storagezusage; umgekehrt kann eine korrekte Image-Kette einen Transportfehler nicht erklären.