Es handelt sich um eine neue Version des älteren Posts KVM/QEMU Thin Provisioning mit QCOW2.

Warum Thin Provisioning

Wer mit dem “Virtual Machine Manager” eine neue VM anlegt, erhält in der Standardeinstellung eine 20GB große Datei mit der Endung .qcow2

Die Dateigröße entspricht der Gesamtgröße der virtuellen Festplatte für diese VM, egal wie viel tatsächliche genutzt wird.

Bei Thinprovisioning wird nur der tatsächlich verwendete Speicherplatz im Hostsystem verwendet. D.h. wenn die VM-Festplatte mit 20GB konfiguriert wird, aktuell aber nur 5GB benutzt werden, so wird im Hostsystem auch nur ca. 5GB Speicher verwendet. Bei mehreren Systemen kann das ganz schön viel Speicherplatz sparen.

Nachteil: wächst der tatsächliche Speicherbedarf in den Virtuellen-Maschinen, wird ev. der zur Verfügung stehende Speicherplatz “gesprengt” und legt ev. das ganze Hostsystem incl. aller VMs lahm …

Dauerhaftes Thin Provisioning

Hier wird ein kleiner Trick verwendet, die eigentlich für SSDs benötigte TRIM-Funktion. Über TRIM teilt das Betriebssystem der Festplatte mit, dass es einen Block nicht mehr benötigt. SSDs können den Block dann speziell löschen um ihn später wieder beschreiben zu können.

Der QEMU-Treiber verwendet diese Funktion nun um den Bereich in der QCOW2-Datei mit neuen Daten beschreiben zu können, da er ja derzeit vom Betriebssystem nicht mehr verwendet wird.

Früher musst man dafür den SCSI-Treiber verwenden, mit den aktuellen qemu, virt-manager und Linux-Kernel Versionen funktioniert dies nun auch mit den “normalen” virtio-Datenträgern.

Dazu ist bei den Datenträger beim Festplattenbus “VirtIO” zu wählen und unter Leistungsoptionen der Discard mode “unmap”.

Ablauf

Prüfe auf dem KVM-Host den freien Speicherplatz auf der Disk wo die qcow2 Dateien angelegt werden (meist unter /var/lib/libvirt/images).

df -h
/dev/mapper/fedora-root 450G  243G 207G 55% /

Lege eine neue virtuelle Maschine mit z.B. 40 GB Diskspace an und prüfe den Speicherplatz erneut:

df -h
/dev/mapper/fedora-root 450G  283G 167G 63% /

Mann sieht, der freie Speicherplatz ist um die 40 GB gesunken.

Jetzt kannst du in der virtuellen Maschine den Trim-Befehl manuell ausführen:

fstrim -va
/:31,1GiB trimmed on /dev/vda1

Jetzt den freien Speicher am Host erneut prüfen:

df -h
/dev/mapper/fedora-root 450G  252G 198G 57% /

Es sind wieder 31GB Speicher mehr zur Verfügung.

Aber halt, warum ist die qcow2-Datei immer noch 41GB groß????

ls -alh
-rw------,1 qemu qemu 41G 7.Jun 13:32 mymachine.qcow2

Weil es sich um ein Sparse file handelt.

du -h
13G mymachine.qcow2

Aufpassen beim Kopieren einer solchen Datei, mit einem normalen cp ist die kopierte Datei dann nämlich wieder 40GB groß.

cp --sparse=always mymachine.qcow2 newmachine.qcow2

Mit der Option –sparse=always wird die Datei dann nicht mehr auf die eigentliche Größe aufgeblasen.

Anmerkungen zu Debian als Gast

Um TRIM automatisch im Betriebssystem zu aktivieren ist folgender Befehle nötig

systemctl enable --now fstrim.timer

Der in Debian 10 enthaltenen Kernel (4.19.x) ist leider zu alt um für virtio-Disks TRIM durchführen zu können. Abhilfe schafft ein Backport-Kernel. Eine Anleitung findest du u.a. hier.