VM mit qcow2 oder auf cifs-Share friert beim Erstellen/Löschen von Snapshots ein

[crmspezi]

Hallo,

ich bin soweit sehr zufrieden mit Proxmox, hab allerdings ein Problem festgestellt, das ziemlich nervig ist.
Ich hab auf meinem Proxmox 5.4-13 eine Windows 10 VM angelegt, deren Festplatten im qcow2-Format in einem ZFS-Storage liegen.

Wenn ich nun einen Snapshot erstelle (egal ob mit oder ohne RAM) oder lösche, friert die VM ein, bis der Vorgang abgeschlossen ist.
Bestehende RDP-Verbindungen zu dieser VM laufen in einen Timeout.

Folgendes habe ich schon versucht:
- auf einer zweiten Maschine einen Proxmox 6 aufgesetzt und die VM importiert => gleiches Problem
- andere VM nicht im qcow2-Format angelegt => keine Probleme mit Snapshots
- die qcow2-Dateien der VM auf eine Openmediavault cifs Freigabe gelegt => gleiches Problem

Hat jemand eine Idee, wie ich das einfrieren verhindern kann?

Das ultimative Ziel ist, dass die qcow2-Dateien auf meiner Openmediavault liegen sollen und die Vorteile von qcow2 würde ich auch gerne nutzen können, aber solange ich mit autosnapshots in kurzer Abfolge (zur Sicherheit) arbeite, ist das Einfrieren zurzeit eine echte Zumutung.

 

[dcsapak]

deren Festplatten im qcow2-Format in einem ZFS-Storage liegen.

prinzipiell keine so gute idee, besser direkt zfs verwenden (kann auch snapshots), cow auf cow macht die sache nicht schneller

Wenn ich nun einen Snapshot erstelle (egal ob mit oder ohne RAM) oder lösche, friert die VM ein, bis der Vorgang abgeschlossen ist.

mhmm snapshot mit ram muss (zumindest kurz) die vm mal anhalten um einen konsistenten ram snapshot zu erhalten

für mich hört es sich so an als wäre der storage sehr langsam, was genau ist denn da drunter? scheint irgendwas in den logs (journal/syslog/dmesg) auf?

 

[crmspezi]

prinzipiell keine so gute idee, besser direkt zfs verwenden (kann auch snapshots), cow auf cow macht die sache nicht schneller


mhmm snapshot mit ram muss (zumindest kurz) die vm mal anhalten um einen konsistenten ram snapshot zu erhalten

für mich hört es sich so an als wäre der storage sehr langsam, was genau ist denn da drunter? scheint irgendwas in den logs (journal/syslog/dmesg) auf?

Hallo dcsapak,
vielen lieben Dank für Deine Antwort.

Also auf dem lokalen Storage 8x 900GB SAS 10K liegt nur ZFS, da laufen Snapshots mit und ohne RAM ohne Timeouts. Verschiebe ich die Disk in ein Verzeichnis auf dem lokalen ZFS Storage, es wird nun eine qcow2 Disk daraus, gehen die Probleme mit und ohne RAM bei Snapshots sofort los.

Das war der Test lokal. Ich möchte allerdings die Disk in einem gemeinsam benutzen Storage halten, auf einer OpenMediaVault NAS , die mit 10 GBit/s angebunden ist (cifs). Der Storage auf der NAS ist ebenfalls ZFS. Die Windows VM ist extrem schnell mit qcow2 Disks von der per cifs angebundenen NAS. Hier habe ich die gleichen Probleme mit Snapshots wie beim lokalen Storage aus einem Verzeichnis.

Übrigens: ZFS over iSCSI (getestet mit NAS4Free/XigmaNAS) habe ich aufgegeben wegen der schlechten Performance im Vergleich zu cifs/qcow2. Ich erreichte nur 10% der Übertragungsleistung im Vergleich zu cifs/qcow2. Auf einer XigmaNAS erreiche ich mit cifs auch eine super Performance.

Mein Fazit: Für mich sind qcow2 Snapshots im laufenden Betrieb von Windows-VMs derzeit leider nicht nutzbar, weil für die Zeit der Snapshot Erstellung keine RDP Verbindung möglich ist. Die Zeiten hierfür liegen selten weniger als bei 20 Sekunden.

Was mir eben auch noch aufgefallen ist. Auch bei ausgeschalteter VM dauert der Snapshot bei qcow2 Disk ca. 20-30 Sekunden, genau die Zeit der Timeouts (Verzeichnis auf ZFS Pool). Getestet auf unterschiedlicher Hardware!

Evtl. hat ja hier jemand ein ähnliches Problem. Ich würde mich sehr über Hilfe von euch freuen.

VG crmspezi

 

[crmspezi]

weiterer Test
ich habe die VM von
cifs OpenMediaVault qcow2 Disk / ZFS Raid-Mirror

auf
cifs OpenMediaVault qcow2 Disk / mdadm Raid5

verschoben.

Timeouts OHNE RAM sind sofort weg!!!
Timeouts mit RAM sind noch vorhanden.

Wieso funktioniert denn das nicht auf einer ZFS Freigabe und was könnte ich hier tun?

VG

 

[dcsapak]

auf
cifs OpenMediaVault qcow2 Disk / mdadm Raid5

verschoben.

Timeouts OHNE RAM sind sofort weg!!!

klingt gut

Timeouts mit RAM sind noch vorhanden.

erwartet wie ich bereits oben geschrieben habe (hängt stark davon ab wie schnell/viel die vm den ram benutzt)

Wieso funktioniert denn das nicht auf einer ZFS Freigabe und was könnte ich hier tun?

wie ich bereits erwähnt habe ist cow (qcow2 file) auf cow (zfs) nicht zu empfehlen

 

[crmspezi]

klingt gut


erwartet wie ich bereits oben geschrieben habe (hängt stark davon ab wie schnell/viel die vm den ram benutzt)


wie ich bereits erwähnt habe ist cow (qcow2 file) auf cow (zfs) nicht zu empfehlen

Ja das verstehe ich auch, aber gibt es evtl. im ZFS (Debian/Openmediavault) ein Flag, das ich setzen kann, damit das nicht passiert? Ich teste das heute noch mit xigmanas (freebsd) qcow2 auf ZFS und berichte dann. Es könnte ja sein das die ZFS Implementierung in Debian das Problem verursacht.

VG

 

[crmspezi]

Nachtrag,
ich habe eben einen Test cifs/qcow2/zfs xigmanas mit den Snapshots ohne RAM gemacht. Hier taucht das Problem NICHT auf. Lediglich auf der OpenMediaVault mit aktuellem PVE Kernel und auf dem PVE qcow2/ZFS/Verzeichnis Es sieht aus, als ob die ZFS Implementierung hier das Problem cifs/qcow2/zfs macht. Hier bleibt möglicherweise nur der Ausweg mdadm Raid1 oder btrfs Raid1.

Hat jemand ähnliche Erfahrungen?

 

[crmspezi]

Nachtrag Test OpenMediaVault btrfs Raid1
cifs/qcow2/btrfs-Raid1 - Snapshots ohne RAM - KEINE Timeouts und Volldampf! mdadm Raid1 wollte ich aus verschiedenen Gründen nicht verwenden.

Fazit bis jetzt: qcow2 auf zfs, egal ob lokal aus Verzeichnis oder über cifs auf zfs Storage ist zwar performant, allerdings sind Snapshots im laufenden Betrieb eine absolute Zumutung. Hier hilft nur freenas oder xigmanas (nas4free) auf freebsd Basis. Dort tritt das Problem gar nicht auf.

Derzeitige Meinung von mir:
Die zfs Implementierung auf Debian (mit pve Kernel), egal ob pve oder OpenMediaVault mit pve Kernel, ist für qcow2 Dateien, bei denen ein Life-Snapshot benötigt wird, wegen des langen Einfrierens der VM, absolut ungeeignet, leider. Jedenfalls habe ich keine Parameter im zfs gefunden die die Performance hier negativ beeinflussen.

VG

 

[crmspezi]

Auch wenn ich hier neben "dcsapak" Alleinunterhalter bin, möchte ich meine Erfahrungen euch nicht vorenthalten.

Das Setzen vom Flag "zfs set sync=off", statt "default" bzw. "standard" bringt alles wieder ins Lot, also KEINE Timeouts. Im Internet habe ich auch dazu gefunden:

Re: sync=standard in zVol

always = ZFS will sync every write to disk immediately, even if ESXi (or whatever app) doesn't ask for it.
standard = ZFS will sync writes when the app asks for it (ESXi always syncs, at least on NFS)
disabled = ZFS won't sync writes whether asked or not. In case of a crash, you will lose a few seconds of writes.

If you have an SSD SLOG, it will be used to sync the write.

Ich bin wirklich überrascht, das dies selbst den Entwicklern von Proxmox nicht aufgefallen ist.
Viele Grüße