qcow2 auf ZFS ?

Jan 9, 2012
282
1
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?
 

dietmar

Proxmox Staff Member
Staff member
Apr 28, 2005
17,047
477
103
Austria
www.proxmox.com
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.

Das macht keinen Sinn, weil ZFS an sich schon snapshots kann - qcow2 braucht man einfach nicht.
 
Jan 9, 2012
282
1
18
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.
 

LnxBil

Famous Member
Feb 21, 2015
5,547
630
133
Germany
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.
 

fireon

Famous Member
Oct 25, 2010
3,808
303
103
39
Austria/Graz
iteas.at
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 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.
 
Jan 9, 2012
282
1
18
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.
Warum genau ist das mehr als fahrlässig? Bitte um genaue Erklärung.
 

LnxBil

Famous Member
Feb 21, 2015
5,547
630
133
Germany
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.
 
Jan 9, 2012
282
1
18
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.
 

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!

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 your own in 60 seconds.

Buy now!