Fragen zu Proxmox VE Einstellungen für VM's

[bogo22]

Hallo,

schön das es ein deutsches Unterforum gibt.
Ich habe ein paar fragen bezüglich Proxmox:

(1) Benutzt ihr ZFS als root-pool/storage? Funktioniert das ohne Probleme? Soweit ich weiss ist dieses feature relativ neu, sodass ich unsicher bin wie stabil das ganze ist. Gibt es Probleme mit dem SWAP-File unter ZFS?

(2.0) Sollte man für neuere Windows VM's (ab Win8/Server 2010 aufwärts) das BIOS 'SeaBIOS' oder UEFI 'OVMF' nutzen? Im Proxmox-Wiki (siehe 'BIOS and UEFI') steht, dass SeaBIOS der Standard ist. Was sollte genutzt werden wenn kein VGA Passthrough benutzt wird? Ich dachte Windows 8 aufwärts bevorzugt UEFI.

(2.1) Falls OVMF genutzt wird, steht im Wiki-Eintrag:
In order to save things like the boot order, there needs to be an EFI Disk. This disk will be included in backups and snapshots, and there can only be one.

Heisst das, dass ich für alle Windows-VM's global nur eine EFI-Disk anlegen muss oder für jede Windows-VM eine eigene EFI-Disk?

(3) Ich habe im englischen Unterforum eine Frage bzgl. ZFS-as-Storage oder ZFS-as-Folder gestellt. (Hier).
Vielleicht weiss hier jemand eine Antwort drauf.

(4) Ebenfalls im englischen Unterforum habe ich eine Frage bzgl. der "Best BIOS Settings" gestellt (Hier).
Ich frage deswegen, da bei anderen Hypervisor einige Einstellungen Probleme machen können (z.B. 'Above 4G'). Speziell interessiert mich, ob ich folgende Einstellungen lieber enabled oder disabled lassen soll:

(A) PCI PERR/SERR Support
(B) Above 4G Decoding (Available if the system supports 64-bit PCI decoding)
(c) ASPM Support​

Besten Dank.

 

[fireon]

(1) Benutzt ihr ZFS als root-pool/storage? Funktioniert das ohne Probleme? Soweit ich weiss ist dieses feature relativ neu, sodass ich unsicher bin wie stabil das ganze ist. Gibt es Probleme mit dem SWAP-File unter ZFS?

Ja ZFS ist absolut stabil setzen es hier auf vielen Servern ein. Wenn man einmal damit warm geworden ist, wirft man jeden Hardwareraidcontroller über die Häuser. Würde dir aber dirgends empfehlen den Rootpool nur für das System zu nutzen, also 2 SSDs für PVE und dann nen eigenen Pool für deine Daten. Es ist von der Verwaltung so wesentlich einfacher. Swap auf ZFS ist natürlich nicht besonderlich gut. Wir liesen ihn bis jetzt immer darauf, haben aber die Swapiness immer auf 0 gestellt. Dann kann nix passieren, sofern genug RAM vorhanden ist. Also nicht überbuchen. Und genug für ZFS einrechnen, ist sehr RAMhungrig.

(2.0) Sollte man für neuere Windows VM's (ab Win8/Server 2010 aufwärts) das BIOS 'SeaBIOS' oder UEFI 'OVMF' nutzen? Im Proxmox-Wiki (siehe 'BIOS and UEFI') steht, dass SeaBIOS der Standard ist. Was sollte genutzt werden wenn kein VGA Passthrough benutzt wird? Ich dachte Windows 8 aufwärts bevorzugt UEFI.

Tja bin mir was das BIOS angeht noch nicht ganz einig. Machte einige Langzeittests mit OVMF, mir ist da die Windowsvm (win10, win2012server) aus unerklärlichen Gründen 2 mal abgestürzt, dann nie mehr wieder. Trotzdem gab es mir zu denken. Auch starteten die VMs nach einem PVE- Update (Enterprise) nicht mehr. Problem war,.. oder ist hier ein Bug wenn man Ramhotplug und OVMF ausgewählt hat. Bleibe also vorerst beim empfohlenen SeaBIOS.
Was VGA Passthrough angeht: Hatte dieses Wochenende meinen ersten nachvollziehbaren Erfolg. Funktioniert hier mit Win2012r2 Server und Kubuntu 16.04 mit einer Quadro K4000 einwandfrei. Über 60 FPS über RDP mit der Unigine. Aber hier geht das nur mit OVMF und die Grafikkarte muss UEFI können. Alles andere ist für die Katz. BTW. Linux mit OVMF stürtzte nie ab.

(2.1) Falls OVMF genutzt wird, steht im Wiki-Eintrag:
In order to save things like the boot order, there needs to be an EFI Disk. This disk will be included in backups and snapshots, and there can only be one.
Heisst das, dass ich für alle Windows-VM's global nur eine EFI-Disk anlegen muss oder für jede Windows-VM eine eigene EFI-Disk?

Für jede VM eine eigene.

(3) Ich habe im englischen Unterforum eine Frage bzgl. ZFS-as-Storage oder ZFS-as-Folder gestellt. (Hier).
Vielleicht weiss hier jemand eine Antwort drauf.

Bitte dort die Antworten entgegen nehmen und spaltet sich das Thema.

(4) Ebenfalls im englischen Unterforum habe ich eine Frage bzgl. der "Best BIOS Settings" gestellt (Hier).
Ich frage deswegen, da bei anderen Hypervisor einige Einstellungen Probleme machen können (z.B. 'Above 4G'). Speziell interessiert mich, ob ich folgende Einstellungen lieber enabled oder disabled lassen soll:

(A) PCI PERR/SERR Support
(B) Above 4G Decoding (Available if the system supports 64-bit PCI decoding)
(c) ASPM Support​

Bitte dort die Antworten entgegen nehmen und spaltet sich das Thema.

 

[bogo22]

@fireon
Danke für die Beantwortung der Fragen (1) - (2.1), das hift mir weiter. Vielleicht findet sich ja noch jemand zu den anderen Fragen im ersten Post.

Ich habe noch zwei weitere Fragen.
(1) Für Windows VM'S wird ja generell für Network- als auch Bus/Device = VirtIO empfohlen.
Nutzt ihr in Windows VM's auch den QEMU-Agent? Dieser soll ja Befehle wie Shutdown etc 'sicherer' machen. Nach meinen Tests braucht eine VM mit aktiven QEMU-Agent viel länger für den shutdown (Bildschirm der VM ist schwarz aber bis das grüne Symbol in Proxmox auf Grau springt dauert es ewig). Auch scheint beim Starten die VM für die erste Minute etwas träger zu sein. Bin mir aber nicht sicher ob es am QEMU-Agent liegt.

(2) Und, nutzt ihr für VM'S allg. den default NoVNC oder SPICE ? SPICE soll mehr Möglichkeiten bieten? Welche genau? Wenn man die VM nur simple steuern möchte ohne Audio, HD Auflösung etc ist NoVNC ausreichend? Im Wiki für SPICE steht, dass man zusätzlich einen 'Viewer' installieren muss... In der Web-GUI von Proxmox funktioniert SPICE aber auch direkt im Browser wie NoVNC.

Ich versuche nur Erfahrung zu sammeln welche Einstellungen für VM's die richtigen sind
Besten Dank.

 

[udo]

... Wir liesen ihn bis jetzt immer darauf, haben aber die Swapiness immer auf 0 gestellt. Dann kann nix passieren, sofern genug RAM vorhanden ist.

Hi fireon,
das ist mit aktuelle Kernel gefährlich. Entgegen bei älteren, meint 0 inzwischen wirklich 0 und swapt nie - das heisst im Fall der Fälle haut Dir der oomkiller irgendwelche VMs (oder anderes) weg...
"swapiness 1" wäre die richtige Wahl.

Udo

 

[tschanness]

@bogo22:
1.: Es wird mit dem Agent ein "echter" shutdown gemacht und nicht nur der Prozess gekillt (unterschied zwischen Stecker ziehen und herunterfahren)
2-: Wenn Spice im Browser funktioniert ist der viewer installiert. Falls die der NoVNC reicht, dann brauchst du den Spice nicht - der könnte halt "mehr".

LG Jonas

 

[bogo22]

Hi fireon,
das ist mit aktuelle Kernel gefährlich. Entgegen bei älteren, meint 0 inzwischen wirklich 0 und swapt nie - das heisst im Fall der Fälle haut Dir der oomkiller irgendwelche VMs (oder anderes) weg...
"swapiness 1" wäre die richtige Wahl.
Udo

In diesem Proxmox Wiki Artikel (ganz unten die Tabelle) werden keinerlei "Gefahren" erwähnt bei vm.swappiness = 0. Es wird halt nur dann geswapt wenn out-of-memory. Wenn sich das geändert hat mit dem aktuellen Kernel sollte man das Wiki anpassen.

@bogo22:
1.: Es wird mit dem Agent ein "echter" shutdown gemacht und nicht nur der Prozess gekillt (unterschied zwischen Stecker ziehen und herunterfahren)
2-: Wenn Spice im Browser funktioniert ist der viewer installiert. Falls die der NoVNC reicht, dann brauchst du den Spice nicht - der könnte halt "mehr".

LG Jonas

-Soweit ich weiss habe ich kein SPICE Viewer installiert. Einfach SPICE ausgwählt und unter OSX mit FIrefox ging es out-of-the-box. Aber einen wirklichen Vorteil habe ich noch nicht gefunden ggü. NoVNC. So wie ich es verstehe ist diese Einstellung aber 'unabhängig' von der VM oder? Also die VM bekommt 'intern' davon nichts mit ob NoVNC nutze oder SPICE.

-Also macht der QEMU Agent bei allen Windows VM's durchaus Sinn und sollte immer aktiviert sein richtig? (Aber kann mir gar nicht vorstellen das ohne QEMU Agent der Host -Proxmox- die Windows VM's immer 'hart' ausschaltet). Wie siehts bei UNIX VM's aus? Gibt es dort auch einen QEMU Agent und passende Treiber?

 

[udo]

In diesem Proxmox Wiki Artikel (ganz unten die Tabelle) werden keinerlei "Gefahren" erwähnt bei vm.swappiness = 0. Es wird halt nur dann geswapt wenn out-of-memory. Wenn sich das geändert hat mit dem aktuellen Kernel sollte man das Wiki anpassen.

Hi,
ja sollte man wohl mal machen... (hab' selbst bloß gerede keine Zeit)
Steht zB. auch in der wikipedia: https://en.wikipedia.org/wiki/Swappiness

vm.swappiness = 1    Kernel version 3.5 and over, as well as Red Hat kernel version 2.6.32-303 and over: Minimum amount of swapping without disabling it entirely.

Udo

 

[dcsapak]

Hi fireon,
das ist mit aktuelle Kernel gefährlich. Entgegen bei älteren, meint 0 inzwischen wirklich 0 und swapt nie - das heisst im Fall der Fälle haut Dir der oomkiller irgendwelche VMs (oder anderes) weg...
"swapiness 1" wäre die richtige Wahl.

Udo

laut kernel dokumentation:

A value of 0 instructs the kernel not to
initiate swap until the amount of free and file-backed pages is less
than the high water mark in a zone.

er wird swappen, aber nur bei einer out of memory situation, was bei uns im wiki auch vermerkt ist... weiß jetzt nicht was da dran falsch ist

 

[udo]

laut kernel dokumentation:


er wird swappen, aber nur bei einer out of memory situation, was bei uns im wiki auch vermerkt ist... weiß jetzt nicht was da dran falsch ist

Hi Dominik,
laut dem hier nicht mehr: https://www.percona.com/blog/2014/04/28/oom-relation-vm-swappiness0-new-kernel/
Und die Quellen, ich ich sonst gefunden habe, schreiben nicht, dass das Verhalten mit dem 4.4er wieder geändert wurde.
Macht in meinen Augen ja auch Sinn, warum sollte 0 nicht auch nicht swappen bedeuten.

Udo

 

[LnxBil]

Ja ZFS ist absolut stabil setzen es hier auf vielen Servern ein. Wenn man einmal damit warm geworden ist, wirft man jeden Hardwareraidcontroller über die Häuser. Würde dir aber dirgends empfehlen den Rootpool nur für das System zu nutzen, also 2 SSDs für PVE und dann nen eigenen Pool für deine Daten. Es ist von der Verwaltung so wesentlich einfacher. Swap auf ZFS ist natürlich nicht besonderlich gut. Wir liesen ihn bis jetzt immer darauf, haben aber die Swapiness immer auf 0 gestellt. Dann kann nix passieren, sofern genug RAM vorhanden ist. Also nicht überbuchen. Und genug für ZFS einrechnen, ist sehr RAMhungrig.

Auch gut ist zram zu benutzen, dass einen Swap-Bereich komprimiert im RAM ablegt und diesen höher priorisiert. Damit wird erst später geswappet. Wobei swappen ja generell keine Gute Idee ist, wenn er aber mal swappen muss, macht er das ins RAM. Klingt komisch, ist aber wesentlich schneller als eine langsame Disk zu verwenden.

 

[LnxBil]

[Nutzt ihr in Windows VM's auch den QEMU-Agent?

Bei Windows ist er vor allem gut für Shadow Copies, die damit angestoßen werden können z.B. beim Backup von außen. Prima Geschichte.

 

[bogo22]

Auch gut ist zram zu benutzen, dass einen Swap-Bereich komprimiert im RAM ablegt und diesen höher priorisiert. Damit wird erst später geswappet. Wobei swappen ja generell keine Gute Idee ist, wenn er aber mal swappen muss, macht er das ins RAM. Klingt komisch, ist aber wesentlich schneller als eine langsame Disk zu verwenden.

Komprimierung ist eigentlich immer eine gute Wahl, da die CPU die Daten schneller bearbeiten kann als eine HDD/SSD. Gleichzeitig werden weniger Schreibzyklen bei einer SSD zugunsten der Lebensdauer benötigt. Falls Proxmox aber auf einem ZFS-Pool (rpool) inkl. SWAP installiert ist und compression=lz4|on|gzip|... gesetzt ist, ist zram meiner Ansicht nach sogar eher kontra-produktiv (doppelte Komprimierung).

Bei Windows ist er vor allem gut für Shadow Copies, die damit angestoßen werden können z.B. beim Backup von außen. Prima Geschichte.

QEMU-Agent also bei Windows VM's von Vorteil Bei Linux-Guest's hat es wahrscheinlich den gleichen Vorteil.

 

[fireon]

-Soweit ich weiss habe ich kein SPICE Viewer installiert. Einfach SPICE ausgwählt und unter OSX mit FIrefox ging es out-of-the-box. Aber einen wirklichen Vorteil habe ich noch nicht gefunden ggü. NoVNC. So wie ich es verstehe ist diese Einstellung aber 'unabhängig' von der VM oder? Also die VM bekommt 'intern' davon nichts mit ob NoVNC nutze oder SPICE.

Je nach Einsatzgebiet gibt es mit Spice einen großen Vorteil. Wir nutzen hier fast nur Spice. Vorab: Spice über WANleitungen unter 15/15 macht da keinen Spass. Großer Vorteil für nur Konsoleninstallation ist wenn man z.B. STRG+W braucht, bei novnc geht da das Fenster zu. Ausserdem geht copy-paste super. Spice und XFCE sind eine der besten Combos. Auch Windows7 bedienst sich hier absolut nativ. Man steckt nen USBstick an und hat das Laufwerk in der VM. Also ich finde Spice einfach genial. Natürlich gilt für alle Betriebssysteme auch hier: Treiber installieren.

-Also macht der QEMU Agent bei allen Windows VM's durchaus Sinn und sollte immer aktiviert sein richtig? (Aber kann mir gar nicht vorstellen das ohne QEMU Agent der Host -Proxmox- die Windows VM's immer 'hart' ausschaltet). Wie siehts bei UNIX VM's aus? Gibt es dort auch einen QEMU Agent und passende Treiber?

Zum Shutdown: Linux immer mit Qemuagent. Sonst fährt z.B. ne Desktop installierte Maschine (z.B. Ubuntu oder ähn.) nicht hinunter wenn da wer eingeloggt ist. Ohne Agent auch kein Shutdown wenn z.B. schon ein Reboot von automatischen Updates geplant wurde, da ja schon ein Shutdownprozess läuft. Generell geht das auch alles mit ACPI, aber nicht ohne viel Anpassungen am System. Der Agent wird auch für Grafikkarten durchreichen benötigt.
Zu Windows: Hier ist es ähnlich, nur halte ich mich hier an die "best practices Anleitungen" im Wiki. Windows bekommt keine Agent, da es absolut unstabil läuft. Weder win7/win10 noch Server Versionen funktionieren damit, mit UEFI ohne UEFI völlig egal. Ab und zu streikt der Dienst schon nach ner Stunde, ab und zu erst nach Wochen, es war für mich noch nicht nachvollziehbar warum. Auch ist die Virtioversion egal. Finde es schade das der Agent in Windows nicht richtig tut. Aber da muss man bei RedHat anklopfen. ACPI tut es ja auch, und falls man ein Backup zurückspielen sollte (backup snapshot)... das muss ein OS aushalten. Ist ja wie Strom weg.

 

[LnxBil]

Komprimierung ist eigentlich immer eine gute Wahl, da die CPU die Daten schneller bearbeiten kann als eine HDD/SSD.

Für LZ4 auf jeden Fall, sonst nein.

Gleichzeitig werden weniger Schreibzyklen bei einer SSD zugunsten der Lebensdauer benötigt.

Aber nur bei Enterprise oder manchen Prosumer SSDs. Gilt z.B. nicht für die Samsung EVO Reihe, denn dort ist es egal ob ich 8 KB oder nur 2 KB schreibe, der Schreibzyklus schreibt eine immer feste, leider viel zu große Blockgröße von einigen MB und somit macht dir ZFS mir kleinen, schnuckeligen Blöcken sehr schnell die SSD kaputt.

Falls Proxmox aber auf einem ZFS-Pool (rpool) inkl. SWAP installiert ist und compression=lz4|on|gzip|... gesetzt ist, ist zram meiner Ansicht nach sogar eher kontra-produktiv (doppelte Komprimierung).

Warum doppelt? Der zram-basierte Swap liegt im RAM, der andere im ZFS auf der Platte / SSD. Sind zwei komplett unabhängige Dinge.

 

[bogo22]

Je nach Einsatzgebiet gibt es mit Spice einen großen Vorteil. Wir nutzen hier fast nur Spice. Vorab: Spice über WANleitungen unter 15/15 macht da keinen Spass. Großer Vorteil für nur Konsoleninstallation ist wenn man z.B. STRG+W braucht, bei novnc geht da das Fenster zu. Ausserdem geht copy-paste super. Spice und XFCE sind eine der besten Combos. Auch Windows7 bedienst sich hier absolut nativ. Man steckt nen USBstick an und hat das Laufwerk in der VM. Also ich finde Spice einfach genial. Natürlich gilt für alle Betriebssysteme auch hier: Treiber installieren.

Das mit COPY-PASTE wusste ich nicht. Falls das gut klappt wäre es schon ein Grund SPICE statt NoVNC zu nutzen. Werde es ausprobieren. Vielen Dank.

Zum Shutdown: Linux immer mit Qemuagent. Sonst fährt z.B. ne Desktop installierte Maschine (z.B. Ubuntu oder ähn.) nicht hinunter wenn da wer eingeloggt ist. Ohne Agent auch kein Shutdown wenn z.B. schon ein Reboot von automatischen Updates geplant wurde, da ja schon ein Shutdownprozess läuft. Generell geht das auch alles mit ACPI, aber nicht ohne viel Anpassungen am System. Der Agent wird auch für Grafikkarten durchreichen benötigt.
Zu Windows: Hier ist es ähnlich, nur halte ich mich hier an die "best practices Anleitungen" im Wiki. Windows bekommt keine Agent, da es absolut unstabil läuft. Weder win7/win10 noch Server Versionen funktionieren damit, mit UEFI ohne UEFI völlig egal. Ab und zu streikt der Dienst schon nach ner Stunde, ab und zu erst nach Wochen, es war für mich noch nicht nachvollziehbar warum. Auch ist die Virtioversion egal. Finde es schade das der Agent in Windows nicht richtig tut. Aber da muss man bei RedHat anklopfen. ACPI tut es ja auch, und falls man ein Backup zurückspielen sollte (backup snapshot)... das muss ein OS aushalten. Ist ja wie Strom weg.

Ok, danke für die ausführliche Erläuterung. Zur Info an alle Interessierten: Es gibt ein neuen angepinnten Foreneintrag mit Video-Tutorial. Hier wird die Installation samt optimalen Einstellungen für Windows VM's gut beschrieben. (KLICK). Gleich eine Frage hierzu: Es soll Bus/Device=SCSI und discard gewählt werden. Discard ist ja primär für das trimmen von SSD gedacht. Falls ZFS als Storage für die VM mit SSD gewählt wurde, sollte discard dort auch aktiviert werden wenn ZFS-on-Linux (bald) eigenständig trimmt? Das wäre ja nochmal eine "Stufe" höher.

...
Warum doppelt? Der zram-basierte Swap liegt im RAM, der andere im ZFS auf der Platte / SSD. Sind zwei komplett unabhängige Dinge.

Ok. Hatte übersehen das zram RAM basiert ist, obwohl der Name schon drauf schließen lässt Trotzdem cached ZFS, falls SWAP auf einem rpool liegt, die Daten auch komprimiert im RAM (sofern nicht optimiert als SWAP-Device). Somit ist es doch "doppelt" oder übersehe ich etwas?

 

[fireon]

Discard ist ja primär für das trimmen von SSD gedacht. Falls ZFS als Storage für die VM mit SSD gewählt wurde, sollte discard dort auch aktiviert werden wenn ZFS-on-Linux (bald) eigenständig trimmt? Das wäre ja nochmal eine "Stufe" höher.

Nicht ganz, dachte das auch zuerst. Aber das hat in dem Fall nix mit SSDs direkt zu tun. Ein Klick auf die Offlinehilfe schaft Licht ins Dunkel:

If your storage supports thin provisioning (see the storage chapter in the Proxmox VE guide), and your VM has a SCSI controller you can activate the Discard option on the hard disks connected to that controller. With Discard enabled, when the filesystem of a VM marks blocks as unused after removing files, the emulated SCSI controller will relay this information to the storage, which will then shrink the disk image accordingly.

Ich aktiviere es immer. Bei Windows und Ubuntu funktioniert das getesteter weise out of the box. Bei CentOS muss man hier noch ein Systemdservice aktivieren, heist irgndwas mit Trim... weis es jetzt leider nicht auswendig.

 

[LnxBil]

Ok. Hatte übersehen das zram RAM basiert ist, obwohl der Name schon drauf schließen lässt Trotzdem cached ZFS, falls SWAP auf einem rpool liegt, die Daten auch komprimiert im RAM. Somit ist es doch "doppelt" oder übersehe ich etwas?

Swap im ZFS zu cachen ist natürlich sehr sinnfrei. So weit ich weiß (und hoffe ohne es gerade zu überprüfen) hält sich Proxmox VE auch an die "offizielle Anleitung", wie man SWAP auf ZFS verwendet und da sieht man, dass er natürlich keine Blocks cached:

https://github.com/zfsonlinux/pkg-zfs/wiki/HOWTO-use-a-zvol-as-a-swap-device

 

[LnxBil]

Nicht ganz, dachte das auch zuerst. Aber das hat in dem Fall nix mit SSDs direkt zu tun. Ein Klick auf die Offlinehilfe schaft Licht ins Dunkel:

If your storage supports thin provisioning (see the storage chapter in the Proxmox VE guide), and your VM has a SCSI controller you can activate the Discard option on the hard disks connected to that controller. With Discard enabled, when the filesystem of a VM marks blocks as unused after removing files, the emulated SCSI controller will relay this information to the storage, which will then shrink the disk image accordingly.

Ich aktiviere es immer. Bei Windows und Ubuntu funktioniert das getesteter weise out of the box. Bei CentOS muss man hier noch ein Systemdservice aktivieren, heist irgndwas mit Trim... weis es jetzt leider nicht auswendig.

Genau. Um es vielleicht nochmal anders zu erklären:

Wenn man eine Datei auf einem Dateisystem in einem Gast löscht wird der Speicherplatz im Gastdateisystem frei, aber nicht in im Host-Speichersystem, denn das bekommt davon nichts mit. Mit TRIM kann man dem Storage sagen, dass es den Block im Host-System freigibt (bei ZFS z.B.) und dann wird der Block dort nicht mehr aufgeführt und gilt dann dort auch als frei.

Das entspricht der oft durchgeführten Operation "freien Dateisystemspeicher mit Nullen überschreiben" in virtuellen Umgebungen, was das gleiche macht, nur extrem lange dauert. Wenn sich das OS gleich selbst darum kümmern kann, wenn es eh gerade die Änderung am Dateisystem vornimmt ist natürlich viel besser. Wenn das Dateisystem wie ZFS gleich damit korrekt umgeht entfallen Dinge wie "Shrink VMDK"-Eskapaden, die man oft in VMware-Umgebungen macht/machen musste um den Speicherplatz der VMDK auf der Platte zu verringern.

z.B. benötigt ein virtuelles Windows 10 mit nur einer paar MB VPN-Software installiert über ein Jahr mehr als ein Vielfaches die Installierte Menge an Daten, die durch Windows-Updates, Installation der selben und Logdateien angehäuft wird. Wenn die Daten nicht dementsprechend immer freigegeben werden benötigt die VM also viel zu viel Platz, auch wenn die VM immer gleich um die 20 GB laut Windows Explorer benutzt hat. Mit eingeschaltetem TRIM auf ZFS würde das nicht passieren (es sei denn man hat viele Snapshots, was in meinem Fall so ist und daher komme ich auf diese irrsinnigen Mengen an Speicher).

NAME                                     USED  LUSED  USEDSNAP  REFER  LREFER  RATIO
rpool/proxmox/3005                       222G   367G      211G  11,3G   17,4G  1.73x
rpool/proxmox/3005@2015_10_01-13_37_36   473M      0         -  12,6G   20,0G  1.65x
rpool/proxmox/3005@2015_10_01-15_00_34   498M      0         -  12,6G   20,0G  1.65x
rpool/proxmox/3005@2015_10_21-16_30_18  5,92G      0         -  8,21G   13,2G  1.67x
rpool/proxmox/3005@2015_09_05-02_46_08  6,35G      0         -  12,2G   19,9G  1.69x
rpool/proxmox/3005@2015_09_12-02_42_45  3,10G      0         -  12,4G   19,9G  1.68x
rpool/proxmox/3005@2015_09_19-02_17_22  3,00G      0         -  12,5G   20,0G  1.66x
rpool/proxmox/3005@2015_10_03-10_20_07  2,98G      0         -  12,7G   20,0G  1.64x
rpool/proxmox/3005@2015_10_10-14_56_51  3,09G      0         -  12,5G   20,0G  1.67x
rpool/proxmox/3005@2015_11_15-19_29_57  2,99G      0         -  10,6G   17,3G  1.70x
rpool/proxmox/3005@2015_11_20-22_44_20  2,02G      0         -  10,8G   17,3G  1.68x
rpool/proxmox/3005@2015_11_28-00_21_01  1,59G      0         -  11,0G   17,6G  1.66x
rpool/proxmox/3005@2015_11_30-11_39_19  1,02G      0         -  11,0G   17,6G  1.66x
rpool/proxmox/3005@2015_12_04-23_20_44  1,54G      0         -  11,1G   17,6G  1.65x
rpool/proxmox/3005@2015_12_14-15_44_16  1,41G      0         -  11,0G   17,7G  1.68x
rpool/proxmox/3005@2015_12_18-21_19_28  1,14G      0         -  11,1G   17,8G  1.67x
rpool/proxmox/3005@2015_12_25-21_11_05  1,40G      0         -  11,3G   17,9G  1.65x
rpool/proxmox/3005@2016_01_01-21_28_13  1,31G      0         -  11,3G   17,9G  1.65x
rpool/proxmox/3005@2016_01_11-10_53_22  1,34G      0         -  11,4G   17,9G  1.64x
rpool/proxmox/3005@2016_01_15-20_20_50  1,46G      0         -  11,6G   18,0G  1.61x
rpool/proxmox/3005@2016_01_22-20_22_02  1,71G      0         -  11,5G   18,0G  1.63x
rpool/proxmox/3005@2016_01_29-20_20_03  1,52G      0         -  11,5G   18,1G  1.63x
rpool/proxmox/3005@2016_02_05-20_13_23  1,88G      0         -  11,7G   18,2G  1.62x
rpool/proxmox/3005@2016_02_12-20_14_54  2,34G      0         -  11,4G   18,3G  1.67x
rpool/proxmox/3005@2016_02_19-20_08_00  3,23G      0         -  11,7G   18,8G  1.67x
rpool/proxmox/3005@2016_02_26-20_08_57  2,39G      0         -  11,9G   18,9G  1.64x
rpool/proxmox/3005@2016_03_04-20_13_38  2,16G      0         -  11,9G   18,9G  1.65x
rpool/proxmox/3005@2016_03_11-20_08_23  1,75G      0         -  11,7G   19,1G  1.70x
rpool/proxmox/3005@2016_03_18-20_10_41  1,46G      0         -  11,6G   19,2G  1.72x
rpool/proxmox/3005@2016_03_25-20_10_17  1,52G      0         -  11,7G   19,3G  1.72x
rpool/proxmox/3005@2016_04_01-20_08_07  1,39G      0         -  11,9G   19,6G  1.73x
rpool/proxmox/3005@2016_04_08-19_49_00  1,54G      0         -  12,2G   19,7G  1.69x
rpool/proxmox/3005@2016_04_15-20_08_22  1,54G      0         -  12,0G   19,8G  1.73x
rpool/proxmox/3005@2016_04_22-21_46_18  1,41G      0         -  11,8G   19,8G  1.75x
rpool/proxmox/3005@2016_04_29-20_03_41  1,35G      0         -  11,9G   19,9G  1.75x
rpool/proxmox/3005@2016_05_06-20_05_58  1,66G      0         -  11,9G   19,9G  1.74x
rpool/proxmox/3005@2016_05_13-20_06_04  1,66G      0         -  11,9G   20,0G  1.76x
rpool/proxmox/3005@2016_05_20-20_00_10  1,87G      0         -  12,1G   20,1G  1.73x
rpool/proxmox/3005@2016_05_27-19_59_36  2,08G      0         -  12,0G   20,1G  1.75x
rpool/proxmox/3005@2016_06_03-20_02_07  2,87G      0         -  12,0G   20,2G  1.76x
rpool/proxmox/3005@2016_06_10-20_02_37  2,56G      0         -  12,4G   20,3G  1.70x
rpool/proxmox/3005@2016_06_17-20_04_04  3,19G      0         -  12,0G   20,4G  1.77x
rpool/proxmox/3005@2016_06_21-09_16_25   977M      0         -  8,47G   14,0G  1.72x
rpool/proxmox/3005@2016_06_24-20_06_35  1,24G      0         -  9,73G   15,2G  1.62x
rpool/proxmox/3005@2016_07_01-20_09_01  1,31G      0         -  10,3G   15,9G  1.60x
rpool/proxmox/3005@2016_07_08-20_06_45  1,41G      0         -  10,5G   16,2G  1.60x
rpool/proxmox/3005@2016_07_15-20_07_16  1,43G      0         -  11,6G   17,7G  1.59x
rpool/proxmox/3005@2016_07_22-19_29_43  1,33G      0         -  12,2G   18,5G  1.58x
rpool/proxmox/3005@2016_07_29-19_30_47  1,35G      0         -  12,5G   18,9G  1.57x
rpool/proxmox/3005@2016_08_05-19_32_31  1,53G      0         -  12,6G   19,0G  1.56x
rpool/proxmox/3005@2016_08_12-19_33_05  1,58G      0         -  13,1G   19,9G  1.58x
rpool/proxmox/3005@2016_08_19-19_34_16  1,49G      0         -  13,4G   20,1G  1.56x
rpool/proxmox/3005@2016_08_26-19_34_39  1,71G      0         -  13,5G   20,2G  1.55x
rpool/proxmox/3005@2016_09_09-19_32_46  2,08G      0         -  13,7G   20,4G  1.55x
rpool/proxmox/3005@2016_09_16-19_32_36  2,33G      0         -  14,2G   21,0G  1.54x
rpool/proxmox/3005@2016_09_23-19_33_13  2,09G      0         -  14,6G   21,5G  1.53x
rpool/proxmox/3005@2016_09_30-19_35_52  1,84G      0         -  14,7G   21,6G  1.53x
rpool/proxmox/3005@2016_10_07-19_37_48  1,82G      0         -  14,7G   21,7G  1.53x
rpool/proxmox/3005@2016_10_14-20_19_59  1,98G      0         -  14,6G   21,7G  1.55x
rpool/proxmox/3005@2016_10_21-20_22_00  1,74G      0         -  15,0G   22,1G  1.53x
rpool/proxmox/3005@2016_10_28-20_25_39  1,88G      0         -  15,1G   22,3G  1.54x
rpool/proxmox/3005@2016_11_12-20_25_09  1,96G      0         -  15,1G   22,7G  1.56x
rpool/proxmox/3005@2016_11_18-20_24_59  1,69G      0         -  15,2G   22,7G  1.56x
rpool/proxmox/3005@2016_11_25-20_27_45  2,28G      0         -  15,4G   22,7G  1.54x
rpool/proxmox/3005@2016_12_02-20_25_24  1,84G      0         -  9,84G   15,5G  1.65x
rpool/proxmox/3005@2016_12_09-20_22_25  1,87G      0         -  10,3G   16,1G  1.64x
rpool/proxmox/3005@2016_12_16-20_23_12      0      0         -  11,3G   17,4G  1.62x

Also VM hat unkomprimiert knapp 18 GB, belegt aber komprimiert 220 GB.

 

[bogo22]

Danke für die Antwort(en)!

Swap im ZFS zu cachen ist natürlich sehr sinnfrei. So weit ich weiß (und hoffe ohne es gerade zu überprüfen) hält sich Proxmox VE auch an die "offizielle Anleitung", wie man SWAP auf ZFS verwendet und da sieht man, dass er natürlich keine Blocks cached:

https://github.com/zfsonlinux/pkg-zfs/wiki/HOWTO-use-a-zvol-as-a-swap-device

Du hast natülich recht.
Ich habe mal schnell in die pve-installer.git/proxinstall geschaut und es scheint so als ob der installer zur Zeit nicht alle Einstellungen auf das swap zvol anwendet.
Folgendes finde ich im install skript nicht:
-o logbias=throughput -o primarycache=metadata -o secondarycache=none -o compression=zle
Kann mich aber auch irren.

 

[fabian]

Danke für die Antwort(en)!



Du hast natülich recht.
Ich habe mal schnell in die pve-installer.git/proxinstall geschaut und es scheint so als ob der installer zur Zeit nicht alle Einstellungen auf das swap zvol anwendet.
Folgendes finde ich im install skript nicht:
-o logbias=throughput -o primarycache=metadata -o secondarycache=none -o compression=zle
Kann mich aber auch irren.

die fehlen tatsächlich noch - bitte einen eintrag auf bugzilla.proxmox.com erstellen, dann fällt das tracken leichter. die einstellungen lassen sich im übrigen auch im laufenden betrieb für bestehende installationen anpassen..