Liebe Qemu-Experten,

ich bin auf dem Gebiet Qemu noch relativ neu und quäle mich seit einigen Wochen mit folgendem Problem:

Ich habe einen Ubuntu-Webserver als Qemu-QCOW2-Image aufgesetzt. Läuft an sich wunderbar. Jetzt habe ich mal geschaut, wie ausgelastet der Webserver bzgl. Festplatte ist:

1
2
3
4
5

webserver:$ df -h
Dateisystem            Größe Benut  Verf Ben% Eingehängt auf
/dev/mapper/webserver-root
                      314G   21G  278G   7% /
[...]

Jetzt schaue ich auf meinem QEMU-Hostsystem nach:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

host$ qemu-img info WEBSERVER.img
image: WEBSERVER.img
file format: qcow2
virtual size: 320G (343597383680 bytes)
disk size: 109G
cluster_size: 65536


host$ ls -lsh WEBSERVER.img
109G -rw-r--r-- 1 root root 109G 2012-02-08 09:20 WEBSERVER.img

Ich habe zwischenzeitlich gedacht, ich hätte das Problem verstanden (Stichwort "sparse file"). Daher habe ich mal einen Tipp befolgt:

1

host$ qemu-img convert -c WEBSERVER.img -O qcow2 WEBSERVER_KOMPRIMIERT.img

Bringt aber nix, hat ewig gedauert und das neue Image ist genau so groß wie das alte...

Kann mir jemand erklären, warum die Image-Datei gut fünf mal so groß ist, wie das eigentliche Datenaufkommen? Oder habe ich irgendwo einen Denkfehler? Danke & viele Grüße whisky2011

whisky2011 schrieb:

Kann mir jemand erklären, warum die Image-Datei gut fünf mal so groß ist, wie das eigentliche Datenaufkommen? Oder habe ich irgendwo einen Denkfehler?

http://qemu-buch.de/de/index.php/QEMU-KVM-Buch/_Speichermedien/_Image-Formate#qcow2

Das Image hat keine Informationen zum Filesystem, welches darin eingesetzt wird. Einmal belegte Sektoren bleiben erhalten, auch wenn aus der Sicht des Filesystems diese 'gelöscht' sind.

Mach folgendes:

• überschreibe alle nicht belegten Sektoren mit /dev/null

• konvertiere das Image wieder in ein qcow2 Image

• das dauert sehr lange und lohnt sich eigentlich nicht

Qcow2 ist auch relativ langsam, da intern neu belegte Sektoren angelegt werden müssen. Ein Raw Image ist schneller und belegt nach der Erstellung auch 0 Byte auf der HD. Das Filesystem des Host kümmert sich dann um neue Sektoren (sparse Files).

Raw kann Sicherungen des Zustandes mit Overlays machen. Ein Basisimage bleibt konstant, alle Änderungen gehen in das Overlay.

http://qemu-buch.de/de/index.php/QEMU-KVM-Buch/_Speichermedien/_Images_anlegen#Overlay-Images_anlegen

I hope, this helps.

rleofield

Danke & viele Grüße whisky2011

Hallo rleofield,

vielen Dank für deine Antwort. Wenn ich das also richtig sehe, dann bringt mein ganzes "Konvertieren" nichts, solange ich die freien Sektoren nicht überschrieben habe, richtig?

Nun, da dieser Vorgang wohl Stunden dauert, ist es wirklich kaum machbar, jede Woche wieder erneut das Image zu verkleinern. Wirklich blöd...

Aber auf RAW-Images umsteigen fällt mir auch schwer. Gut, das mit dem Overlay gefällt mir ganz gut, aber wenn ich richtig informiert bin, bietet qcow2 doch noch einige andere Vorteile (z.B. Verschlüsselung). Im von dir beschrieben Link steht

Das Format qcow2 ist das vielseitigste Format.

Und etwas weiter unten wird noch von kleineren Problemen gesprochen, wenn das Dateisystem des Hosts keine Sparse-Dateien unterstützt. Das dürfte ggf. bei einem FTP-Backupserver zum Problem werden, oder?

Ich bin jetzt ein wenig durcheinander, welches Format ich wirklich verwenden soll. Aber so wie es derzeit ist, ist es auch nicht wirklich brauchbar. Mein Ziel war, ein Backup vom Server (2 oder 3 GB) einfach zu erledigen, indem ich die komplette VM sichere. Das ist ja gerade ein toller Vorteil. Wenn jetzt mein 2 GB-Webserver im Image auf 100 GB anwächst, dann ist das einfach nur ********

Hast du da noch Tipps / Empfehlungen? Oder muss ich das einfach mit meinem Gewissen aushandeln, welches Format ich zukünftig verwende?

Viele Grüße Whisky2011

whisky2011 schrieb:

Hallo rleofield,

vielen Dank für deine Antwort. Wenn ich das also richtig sehe, dann bringt mein ganzes "Konvertieren" nichts, solange ich die freien Sektoren nicht überschrieben habe, richtig?

Ja.

Nun, da dieser Vorgang wohl Stunden dauert, ist es wirklich kaum machbar, jede Woche wieder erneut das Image zu verkleinern. Wirklich blöd...

Ist so. Große Files sind immer ein Problem.

Aber auf RAW-Images umsteigen fällt mir auch schwer. Gut, das mit dem Overlay gefällt mir ganz gut, aber wenn ich richtig informiert bin, bietet qcow2 doch noch einige andere Vorteile (z.B. Verschlüsselung). Im von dir beschrieben Link steht

Das Format qcow2 ist das vielseitigste Format.

Ja, qcow2 ist sehr weit entwickelt, hat aber auch das Problem, dass geänderte Sektoren drin bleiben.

Und etwas weiter unten wird noch von kleineren Problemen gesprochen, wenn das Dateisystem des Hosts keine Sparse-Dateien unterstützt. Das dürfte ggf. bei einem FTP-Backupserver zum Problem werden, oder?

Ja, Sparse muss durchgängig vorhanden sein. 'rsync' kann Sparse, 'cp' auch, aber ftp nicht, SAMBA mit Tricks. D.h. viele NAS Devices sind für virtuelle Maschinen nicht sehr geeignet.

Ich bin jetzt ein wenig durcheinander, welches Format ich wirklich verwenden soll. Aber so wie es derzeit ist, ist es auch nicht wirklich brauchbar. Mein Ziel war, ein Backup vom Server (2 oder 3 GB) einfach zu erledigen, indem ich die komplette VM sichere. Das ist ja gerade ein toller Vorteil. Wenn jetzt mein 2 GB-Webserver im Image auf 100 GB anwächst, dann ist das einfach nur ********

Ich hab da auch lange probiert. Jetzt mache ich es so:

• VM - raw Image, das wird gesichert, einmalig

• + Overlay, das wird täglich gesichert

• nach einiger Zeit 'commit' und ein neues Overlay.

• danach beide Files wieder sichern

alternativ: aus der VM heraus, die Daten mit Mitteln der VM sichern.

Hast du da noch Tipps / Empfehlungen? Oder muss ich das einfach mit meinem Gewissen aushandeln, welches Format ich zukünftig verwende?

Hier ist ein Text, der meine Erfahrungen mit KVM beschreibt, so, wie ich es z.Zt. mache, kein komplettes Buch:

http://lug-ottobrunn.de/wiki/Virtualisierung_mit_KVM#Image_anlegen

Es gibt für KVM auch sehr gute Wartungstools, aber die kenne ich nicht.

I hope, this helps.

rleofield

Viele Grüße Whisky2011

Hallo rleofield,

besten Dank! Syntax, Config usw. kann man sich ja auch als Anfänger aus allen möglichen Quellen holen. Aber die richtig guten Tipps, die bekommt man nur "so nebenbei" in Foren usw.

So finde ich z.B. deine Idee, nur Overlays zu sichern, echt gut! Da muss ich mal drüber nachdenken. Hat viele Vorteile... - inkrementelle Sicherung sehr leicht möglich - geringes Backup-Volumen (also auch für WAN denkbar) - Raw-Dateien

Die Wartungstools kenne ich leider auch nicht, ich habe alleine schon viele Tage lang mit QEMU gearbeitet, ohne überhaupt den Monitor zu beachten

Ich werde das mal mit den Overlays ausprobieren. Dank KVM kann man sich ja beliebig viele Spielplätze herrichten.

Vielen Dank für den Tipp und viele Grüße! Whisky2011

Hallo rleofield,

ich möchte nochmal auf deine Erfahrung zurückkommen. Sehe ich das richtig, dass Overlay-Images nicht im laufenden Betrieb mit dem Base-Image verschmolzen werden können? Nach deinem Plan müsste ich also meine VM z.B. einmal die Woche herunterfahren, oder? Das wäre für hochfrequentierte Server ja nicht ganz so optimal.

Oder gibt es da eine andere Möglichkeit?

Danke & Gruß whisky2011

whisky2011 schrieb:

Hallo rleofield,

ich möchte nochmal auf deine Erfahrung zurückkommen. Sehe ich das richtig, dass Overlay-Images nicht im laufenden Betrieb mit dem Base-Image verschmolzen werden können?

Ja.

Overlays sind auch nicht inkrementell. Sie sind eine gute Möglichkeit die Backup-Daten zu limitieren, Zerstörungen des Images vorzubeugen und ohne Tools zurückzusetzen.

Es können beliebig viele Overlays pro Base-Image angelegt werden. Da ist hilfreich, wenn man z.B. mehrere Versionen des gleichen Windows haben will.

Und es kommt immer noch vor, dass die Filesysteme im Image kaputt gehen können und die VM nicht mehr bootet (Win-XP ist da so ein Kandidat), da schützen Overlays.

Im Produktivbetrieb würde ich auf 'virsh' ausweichen (ist hier im Wiki).

'virsh' kann leider keine Overlays verwenden und die Konfiguration erfolgt über XML, was sich in Scripten nicht gut macht. Es gibt eine nette GUI, die recht stabil ist.

Schau mal hier, hier steht das, was ich weiß:

//lug-ottobrunn.de/wiki/Virtualisierung_mit_KVM:

Nach deinem Plan müsste ich also meine VM z.B. einmal die Woche herunterfahren, oder? Das wäre für hochfrequentierte Server ja nicht ganz so optimal.

Ja, es geht aber mit den Overlays sehr schnell.

Hat man keine Overlays, kann man im laufenden Betrieb Snapshots machen, die aber im Image liegen. Die Sicherung der Images bliebt als Problem offen. Ich würde eine 2. HD nehmen und nach jedem Snapshot das Image wegschreiben, dass sollte ohne Downtime gehen. habe ich aber nicht getestet.

Oder gibt es da eine andere Möglichkeit?

s.o.

Gruß

rleofield