KVM: Thin Provisioning

Im Folgenden ist "Host" der Rechner, auf dem viele virtuelle Maschinen ("Gäste") laufen. Es wird mehrfach von Nullen die Rede sein, womit binäre Nullen, also Bytes mit dem Wert 0x00 gemeint sind.

Problem: Festplattenplatz

Die Festplatte eines Gastes wird i.d.R. als Datei abgelegt, als sogenanntes Disk-Image. Es wäre große Verschwendung, den verfügbaren Platz eines Hosts komplett auf die Gäste aufzuteilen - z.B. eine 1000GB-Partition auf dem Host mit zehn 100GB-Dateien voll zu packen, damit die Clients notfalls so viel benutzen können, obwohl ihnen typischerweise je 20 GB reichen sollten und man somit meist Platz für bis zu 50 Gäste hätte.

Idee: Thin-Provisioning

Das RAW-Format benötigt¹ für ein 100GB-Disk-Image auch 100GByte auf der Host-Festplatte. Es empfiehlt sich daher, das QCOW2-Format zu verwenden, da dort erst einmal nur der belegte Platz des Gastes benötigt wird - z.B. 20 GByte. Der Gast "sieht" aber die konfigurierten 100 GByte und kann diese auch verwenden. Dabei wächst die Datei auf dem Host mit - bis die 100GByte erreicht sind. Da dieser Extremfall i.d.R. nicht auftritt, kann man mit etwas Reserve den Gästen in Summe sehr viel mehr Plattenplatz versprechen, als insgesamt vorhanden ist.

• Problem 1: Wenn zu viele Gäste gleichzeitig ihren Platz in Anspruch nehmen, so ist die Hostplatte voll! Ein Admin-Eingriff ist notwendig. Dieses Problem lösen Statistiker und Leute, welche sich mit Serverüberwachung beschäftigen.
• Problem 2: Wenn Gäste abwechselnd für eine gewisse Zeit überdurchschnittlich viel Platz belegen und dann die überzähligen Dateien (z.B. Windowsupgrade) wieder löschen, so bleibt das jeweilige Disk-Image erst einmal zu groß. Man muss also den nicht mehr genutzten Platz wieder frei geben, damit er einem anderen Gast zur Verfügung steht. Wir müssen dazu die Information über die Freigabe des Platzes im Gast (Dateien werden gelöscht) weitergeben:

Methode 1 (historisch): Festplatte füllen, dann leeren

Eine früher oft beschriebene Vorgehensweise basiert auf dem Wissen, dass im Gast gelöschte Dateien zwar nicht mehr im Verzeichnis auftauchen und ihre Datenblöcke irgendwann überschrieben werden, aber vorläufig noch auf der Festplatte vorhanden sind. Überschreibt man den gesamten als frei deklarierten Platz mit Nullen, so sind die Dateien endgültig vernichtet.
Dann kann man die Festplattendatei optimieren lassen, so dass Blöcke mit Nullen keinen Platz mehr belegen.

Nachteile

• In unserem Beispiel werden sinnlos 80GB Nullen geschrieben, dann die 100GB-Datei eingelesen und als neue 20GB-Datei geschrieben.
  
• Der komplette "versprochene" Platz wird zumindest kurzfristig benötigt!
  
• Für einige Minuten ist der Gast (ggf. ein wichtiger Server) nicht benutzbar. Dienste sollten heruntergefahren sein um Abstürze zu vermeiden.

Vorteil

• keine Unterstützung des Gast-Betriebssystems nötig
  (man könnte die Nullen auch remote auf die virtuelle Platte schreiben oder die virtuelle Maschine vorübergehend mit einem anderen Betriebssystem booten.)

Methode 2 (modern): discard/TRIM

Hintergrund:

Alle Betriebssysteme haben für SSDs lernen müssen, wie man den nicht benutzten Platz an den Datenträger meldet. So können die Speicherstellen freigegeben werden und von der SSD für das gleichmäßigere Verteilen von Schreibzugriffen genutzt werden können. Der Vorgang wird meist TRIM, Trimmen oder discard genannt. Dies nutzen wir auf dem Gast.

Andererseits können unter Linux in Dateien mehrere Lücken sein, die zwar logisch mit Nullen “gefüllt” sind, aber keinen Platz auf der Festplatte benötigen. Solche Dateien nennt man Sparse-Files. Dies nutzen wir auf dem Host.

So läuft das ideale Zusammenspiel ab:

• Auf dem Gast wird eine Datei gelöscht
  (in seiner Festplattenverwaltung wird der Platz, z.B. Block 666777, als frei gekennzeichnet)

• per Trim des Clientbetriebssystems wird der frei werdende Speicher (z.B. sofort oder wöchentlich) an die virtuelle Festplatte gemeldet
  (die Info, dass 666777 nicht mehr benötigt wird, wird an die virtuelle Festplatte weitergereicht)

• Auf dem Host erhält KVM diese Information und gibt den entsprechenden Speicher in der Festplattendatei auf dem Host frei
  (KVM belegt keinen Platz mehr für Block 666777, der in der Datei als Block 4545 gespeichert war)

• Die Festplattendatei des Gastes hat nun eine Lücke mehr, und belegt somit auf der Host-Festplatte weniger Platz.
  (Das Filesystem des Hosts hat die Information erhalten, dass in der Festplattendatei der Block 4545 mit Nullen belegt ist und braucht dafür so gut wie keinen Platz mehr auf der echten Festplatte.)

Damit dies funktioniert muss einerseits der Gast trimmen können und KVM die Freigabe auch verarbeiten:

Gast anpassen (SCSI)

Die virtuelle Festplatte für den Gast muss für ihn eine SCSI-Festplatte an einem VIRTIO-SCSI-Controller sein (ggf. nachträglich geändert - Backup gemacht?), da KVM nur bei dieser den “discard”-Mechanismus beherrscht. Wenn möglich gleich bei Details/Erweiterte Optionen/Mode verwerfen den Eintrag unmap wählen.

• Für einen Linux-Gast kann man meist auch nachträglich von IDE oder virtio auf SCSI wechseln. Die notwendigen Treiber sind im Linuxkernel i.d.R. enthalten.

• Installation eines Win10/11-Gastes²:

  • Dafür benötigt man die stable Windows-Virtio-Treiber-CD von Fedora (z.B. im Okt. 2025 die getestete Datei virtio-win-0.1.285.iso).
  • Vor der Windowsinstallation die Einstellungen der virtuellen Maschine anpassen: Festplatte als SCSI, dazu den SCSI-Controller virtio-scsi hinzufügen
  • Zweites CD-Laufwerk anlegen und mit der Treiber-CD-Datei virtio-win-0.1.285.iso verbinden.
  • Bei der Installation wird keine Festplatte gefunden. Jetzt auf Treiber laden klicken und von der zweiten CD laden lassen.
  • Installation normal durchlaufen lassen.

• Nachträgliches Ändern der Boot-Platte eines Win10/11-Gastes³:

  • CD-Laufwerk mit der Treiber-CD-Datei verbinden (wie oben).
  • einen VIRTIO-SCSI - Controller hinzufügen
  • neue winzige virtuelle Mini-Platte als VIRTIO-Festplatte hinzufügen, booten.
  • Treiber im Gerätemanager installieren ("aktualisieren", CD auswählen), durchbooten, dann komplett herunterfahren (mit Shift)
  • Boot-Platte auf VIRTIO-SCSI umstellen, Bootreihenfolge prüfen, booten - spätestens wenn es funktioniert: miniDisk wieder entfernen

KVM ergänzen (unmap)

KVM muss ggf. noch angewiesen werden, wie es mit freigegebenen Speicherbereichen in den Disk-Images umgehen soll: Der Speicher soll im Filesystem des Host-Betriebssystems freigegeben werden - der Fachbegriff ist hier “unmap”. Dies kann man in der Konfiguration des virtuellen Speichers im virt-manager anklicken: bei Details/Erweiterte Optionen/Mode verwerfen den Eintrag unmap wählen.

Gast vollenden (TRIM)

Nun den Gast wieder starten.

• Gast: Testen ob Trim aufrufbar ist
  • Linux: sudo fstrim -av
  • Win10: Laufwerk optimieren (im Explorer durchklicken: Laufwerk->Eingenschaften->Tools->Optimieren)
• Host: Prüfen, ob Trim bei der Datei auf dem Host etwas verändert (ls -hls, siehe unten)
• Bei Erfolg:
  • Im Linux-Gast Trim automatisch regelmäßig ausführen lassen:
    • via crontab (Datei in cron.weekly mit fstrim -a) oder besser
    • systemd (aktivieren von fstrim.timer mit sudo systemctl unmask fstrim.timer && sudo systemctl start fstrim.timer).
  • Ein Win10-Gast optimiert automatisch wöchentlich (anscheinend auch nach einer größeren Lösch-Aktion)
• Fehlersuche: Bei einer Platte, die partout nicht zu trimmen war, erwies sich die KVM-Konfigurationsdatei als zu alt:
  • Plan A: Ändere einzelne Einstellungen (Maschinentyp) in der XML-Datei und hoffe.
  • Plan B: Kopiere das Disk-Image, lege eine neue Gastmaschine an in der du die kopierte Datei nutzt und lass die neue Maschine laufen.

Nachbetrachtung

Man muss natürlich damit rechnen, dass obiges Vorgehen immer auch einen Leistungsverlust bei den Festplattenzugriffen bedeutet. Sparse-Files haben nun einmal den Ruf, dass sie im längeren Gebrauch zu einer Fragmentierung der Host-Festplatte führen. Das stört aber nur Benutzer einer echten Festplatte. Mit SSDs ist das kein praktisches Problem. Außerdem kann man jederzeit die unten beschriebene Konvertierung in eine neue Datei durchführen, wodurch auch eine Fragmentierung behoben werden dürfte.

Vorsicht: Bei einer Datensicherung mit z.B. cp oder scp werden die freien Bereiche voll als Nuller übertragen. rsync kann es besser oder man sichert gleich eine optimierte qcow2 datei. Siehe unten:

Handwerkszeug

Test: Dateigrößen

Merke: Das qcow2-Format von KVM erzeugt "sparse"-Dateien. Diese können & werden Lücken haben. Unbenutzter Platz kann logisch als mit Nullen gefüllt angesehen werden. Dies wird dem Host-Betriebssystem (genauer: EXT4-Treiber) mitgeteilt, der das entsprechend vermerkt und dafür keinen Festplattenplatz benötigt. Man kann übrigens auch beliebige Dateien, die Blöcke mit Nullen enthalten, verkleinern, in dem man fallocate -d dateiname aufruft.

ls -hls
du *.qcow2*

Die logische Größe ist wichtig, falls man ein Backup ohne weitere Vorkehrungen über’s Netz schiebt: Diese Größe wird übertragen, auch wenn sehr viele Nullen dabei sind. Gezippt sollte das kaum ein Problem sein, kostet aber Zeit. Rsync kann wie immer auch dieses Problem lösen.

Tipp: Konvertieren der QCOW2-Datei

Enthält eine QCOW2-Datei Leerstellen (echte Nullen oder Lücken via sparse-file), so kann man die Datei verkleinern lassen, in dem man sie in eine neue Datei konvertiert. Dabei werden die Leerstellen im qcow2-Format selbst abgebildet und nicht auf Basis von Sparse-Files.

Dies erledigt bei heruntergefahrenem Gast folgende Befehlsfolge (Backup vorhanden?):

mv gast.qcow2 gast.org
qemu-img convert -O qcow2 gast.org gast.qcow2

Dies kann man natürlich auch zum Zweck eines Backups machen:

qemu-img convert -O qcow2 gast.qcow2 /backup/ziel/pfad/gast.qcow2

Wer wirklich auf den Platzbedarf achtet, kann den zusätzlichen Parameter -c zum Komprimieren mitgeben. Dies ist gerade bei Backups sinnvoll. Der Vorgang dauert auch mit mehreren Prozessorkernen deutlich länger. Belegte Sektoren werden jetzt komprimiert, beim späteren Überschreiben aber wieder unkomprimiert abgelegt. Dies führt z.B. zu folgenden Einsparungen:

• bei einem frischen Debian Buster XFCE von 4,2GB auf 1,5GB Platzbedarf.
• bei einem frischen Win10 1909 von 15 GByte auf 7 GByte

Bei zukünftigen Schreibzugriffen muss man nun mit leichten Tempoeinbußen rechnen. Auch die Fragmentierung nimmt überdurchschnittlich zu - bei SSDs harmlos.

Geht es jedoch mehr um Performance, so kann man stattdessen beim Konvertieren den Parameter -o preallocation=metadata mit angeben. Das kostet wenig echten Plattenplatz, legt aber bereits alle Metadaten der qcow2-Datei an. Zukünftige Schreibzugriffe sollten entsprechend schnell sein. Ein Vergleich fand sich hier.

Deutlich ausführlicher hier nachzulesen mit vielen weiteren englischen Quellen.

Hier eine ausführlichere englische Quelle zum Trimmen in KVM.

Update: Am 4. Okt 2025 überarbeitet und erneut mit Win10 und Win11 getestet. Veraltetes gekürzt.

Christian Bienmüller