qcow2 auf ZFS ?

T

trendco

Member
Proxmox Subscriber
Jan 9, 2012
282
2
18
Anlsässich eines Posts in einem anderen Thread (https://forum.proxmox.com/threads/qcow2-disk-shrinken.39153/#post-193739) mach ich hierzu mal ein neues Thema auf.

Hintergrund:
Ich betreibe seit längerem 2 Server die beide unter ZFS (rpool/mirror) laufen. Darauf habe ich u.a. auch ein paar VM's die qcow2 als Disk benutzen, weil ich die Snapshot-Funktionalität davon sehr schätze, auch mit dem Wissen das qcow2 auf ZFS nicht gerade die performanteste Lösung ist.
In der ganzen Zeit hatte ich bis dato (zum Glück) noch keinerlei Probleme mit diesem Setup und war jetzt doch recht verwundert über die Aussage, dass es hierbei unter Umständen zur Daten-Corruption kommen kann.
Wäre klasse wenn das einer fürs Verständnis mal genau erklären könnte?
 
trendco said:
Ich betreibe seit längerem 2 Server die beide unter ZFS (rpool/mirror) laufen. Darauf habe ich u.a. auch ein paar VM's die qcow2 als Disk benutzen, weil ich die Snapshot-Funktionalität davon sehr schätze, auch mit dem Wissen das qcow2 auf ZFS nicht gerade die performanteste Lösung ist.
Click to expand...

Das macht keinen Sinn, weil ZFS an sich schon snapshots kann - qcow2 braucht man einfach nicht.
 
Ich sehe das nicht ganz so Dietmar.

Bei qcow2 habe ich Disk-Files die ich in bestimmten Szenarien eben möchte/brauche und ich kann bzgl. Rollback im ganzen Snapshot Baum hin & her springen wie ich will, was bei ZFS Snaps eben so nicht geht, bzw. nur über den Umweg Clone oder Snaps dazwischen löschen. Von daher macht es, zumindest für mich, schon Sinn.
 
Ja, muss @trendco da zustimmen. Der Snapshot-Baum und das Springen darin ist ein nicht wegdiskutierbarer Vorteil dieser Lösung - wenn auch der Einzige gegenüber ZFS direkt. Ich habe diese Lösung auch für einige Testmaschinen im Einsatz und möchte sie nicht missen. Kombiniert mit eigenen ZFS-Dateisystemen pro VM erhält dann alle Vorteile der beiden Technologien.
 
trendco said:
Ich sehe das nicht ganz so Dietmar.

Bei qcow2 habe ich Disk-Files die ich in bestimmten Szenarien eben möchte/brauche und ich kann bzgl. Rollback im ganzen Snapshot Baum hin & her springen wie ich will, was bei ZFS Snaps eben so nicht geht, bzw. nur über den Umweg Clone oder Snaps dazwischen löschen. Von daher macht es, zumindest für mich, schon Sinn.
Click to expand...

Ja das stimmt so, wir haben einige unserer Entwicklungsmaschinen auch auf qcow2. Ein Teil auf ZFS und LVM-Thin haben natürlich auch. Alles für seinen Zweck.

@trendco aber wenns dir um die Snapshots geht, dann nimm bitte deine VM's runter, mach ein LVM mit Ext4 draus und spiel sie wieder als qcow2 zurück. Das mit ZFS da drauf ist mehr als fahrlässig, da hattest wirklich noch Glück. Außerdem verlierst hier on top in der Konstellation einiges an Performance.

BTW: weis jetzt nicht ob LVM-Thin den Snapshotbaum auch so verwalten kann. Wäre von der Stabilität natürlich besser. LVM-Thin ist aber bei alten Server zwecks Performancescheinbusen beim Recovern oder auch viel Daten auf einmal schreiben nicht zu empfehlen.
 
Ich starte nun noch mal einen Versuch:

Bitte erkläre mir doch jemand technisch im Detail, was genau in welchem Szenario hier ein Problem verursachen kann?

Für mich gilt bis dato folgendes:
ZFS ist ein sehr sicheres Dateisystem und ZFS ist es egal welche Daten es beherbergen muss.

Warum soll es nun ausgerechnet qcow2 Dateien nicht egal sein wo sie liegen? Das würde ja dann im Umkehrschluss auch bedeuten, dass man keine qcow2 Images auf einem ZFS-SAN ablegen dürfte das per NFS an Proxmox angebunden ist?

Für mich gibt es einfach keine technisch schlüssige Erklärung.

@trendco aber wenns dir um die Snapshots geht, dann nimm bitte deine VM's runter, mach ein LVM mit Ext4 draus und spiel sie wieder als qcow2 zurück. Das mit ZFS da drauf ist mehr als fahrlässig, da hattest wirklich noch Glück.
Click to expand...
Warum genau ist das mehr als fahrlässig? Bitte um genaue Erklärung.
 
Wir haben das auch in diesem Thread (https://forum.proxmox.com/threads/no-qcow2-on-zfs.37518/) schon besprochen und es war damals auch schon "nur" performance. Ich kann mir auch nicht vorstellen was da kaputt gehen soll, zumal ich das seit Jahren auch im Einsatz hab (nicht für Produktion, aber eben für VMs bei denen ich immer zwischen Snapshots hin- und herspringen muss).

Auch eine Recherche im Internet brachte nichts großes, außer, dass es eben auf den Caching-Mechanismus ankommt, da man dort eben nicht "no cache" verwenden kann wegen dem O_DIRECT-Problem von ZFS Dateisystemen (O_DIRECT klappt auf ZVOL, daher soll man das verwenden). Wenn man damit leben kann ist es IMHO kein Problem - aber überzeugt @trendco und mich gerne vom Gegenteil, bitte.
 
Ich benutze übrigens bei den wichtigen VM's "writethrough", bei den eher unwichtigen "writeback". Die Performance ist für mich mehr als ausreichend, selbst mit "writethrough" rennen die 1a auf den ZFS-Mirror-SSD's.
 
Hi, ich möchte das nochmal aufnehmen. Ich nutze einen Proxmox Backup Server mit ZFS - das klappt richtig gut. Ich nutze allerdings je 2 qcow2 Laufwerke als Basis. Das führt bei einem der Setups dazu (ich habe 2 ZFS), dass das qcow2 scheinbar auf die gesamte Größe ausgenutzt wird (obwohl nur knapp 50 % belegt sind) - in einem 2. Setup wird im qcow2 File nur ein Teil als belegt angezeigt. Beide Setups sehen für mich nahezu identisch aus. Das ganze ist dann problematisch, wenn der Plattenplatz eben voll ist und System meint: ist nich. Eigentlich sollte qcow2 nur das an Platz belegen, was es auch braucht.
Auch in der Basismaschine zeigt mir der Graph an, dass das erste ZFS voll ist - das 2. aber nur mit 50 % belegt. Wie kann ich das qcow 2 dazu bewegen, nur den belegten Platz anzuzeigen. Konvertierung mit qemu-img convert ist etwas schwer, da der Plattenplatz fehlt.
 
qemu-img info könnte dir da helfen, aber ohne Konvertierung wirst du es nicht kleiner bekommen. Gibt es Gründe für QCOW2 oder einfach so das auf ZFS zu verwenden? Gerade den freien Speicherplatz auch wirklich frei bekommen ist ja einer der Vorteile von ZFS (trim im Gast), wenn die Daten nicht an einen Snapshot gebunden sind. Das bietet QCOW2 halt leider nicht online.
 
Hi, qcow2 war in dem Moment die einfachste Lösung, da ich für das ZFS 2 Laufwerke benötigte.
Das Info bringt übrigens:
file format: qcow2
virtual size: 11.6 TiB (12777527705600 bytes)
disk size: 10.7 TiB
cluster_size: 65536
Format specific information:
compat: 1.1
compression type: zlib
lazy refcounts: false
refcount bits: 16
corrupt: false
extended l2: false

Heisst also, da ist noch mehr drin, als ich im Proxmox Backup sehe. Können das Snapshots sein?
Dann werde ich aber wohl um ein Convert nicht herum kommen.

Olaf
 
Proxmox Backup lies mich das nur mit 2 separaten Laufwerken als Basis anlegen. Das qemu-img sagt: keine Snapshots. Also geht nur der Weg über das Convert. Danke
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom