[Sammelthread] Proxmox Stammtisch

[layerbreak]

@layerbreak Hier ist der Thread für deine Fragen.

Danke, kannte ich gar nicht.

 

[pwnbert]

Ich bin da immer noch ein bissl unschlüssig, was mein Proxmox Setup angeht.
Vielleicht könnt ihr mir ein wenig helfen?

Einleitung:
Also, die Sache ist die, ich möchte eigentlich eine "all-in-one" Gurke als NAS haben, eh wie jeder. Eierlegende Wollmilchsau. Schnell, stark, flexibel, sparsam, lautlos.
Momentan hab ich ein TrueNAS (B550 Riptide, 5750G) als Filer und ein Proxmox (MC12LE0, 5650G) zum rumspielen und für VMs.
Zukünftig soll das B550 Riptide mit dem 5750G mein "produktiv-Server" sein und das MC12 ne reine Testgurke und später Backupserver (hab noch ein 2. MC12 liegen... mal sehn).

Aufbau:
Das Setup soll ein Proxmox sein mit einer TrueNAS VM (ich mag das NAS nicht direkt in Proxmox machen, ich fühlm ich wohler mit TrueNAS als Filer, das Setup in dieser Art entspricht einfach mehr meinem Denken und meinen Kompetenzen).
Hardware:
Asrock B550 Riptide, 5750G, 128gb DDR4 3200er ECC... 9400-16i HBA (samt ein paar HDDs und SSDs hinten dran), 2x 2tb Kc3000, 2x 4tb Fury Renegade (und ein NanoKVM).

Proxmox:
Hierfür hätte ich 2x 2tb KC3000 vorgesehen, als Mirror.
Proxmox selbst sowie den Speicher für diverse VMs hätte ich gern auf diesem Mirror liegen.
Hier die eigentlichen Fragen:
Wie mach ich das am besten bei der Einrichtung?
- Wie groß macht man den Speicherplatz fürs Proxmox selbst?
- Nimm ich ZFS oder vllt. doch Ext4? So aktuelle Backups brauch ich eigentlich nicht, die VM Sache selbst nicht nicht soo wichtig, wirklich wichtig ist eigentlich nur das NAS. Die Frage zielt etwas auf Write-Amplification ab, sollte bei der Heimanwendung ja nicht so das Thema sein, aber trotzdem... ich bin mir nicht sicher, ob in dem Fall ZFS so der wahnsinnge Vorteil ist, oder ob ext4/xfs nicht voll okay wäre.... hm.
- Eine Micron 7400pro mit PLP hätte ich noch, ggf. als SLOG fürs ZFS denkbar, wenn man damit die Schreiblast wirklich merklich reduzieren würde... bin da auch noch nicht zu 100% dahinter gekommen, wie sich nun ein Non-PLP-VDEV mit einem PLP SLOG verhält... das Ding verbraucht doch 7W, wenn sinnlos ist, bleibts draußen.
- Für die VMs dann LVM-Thin?
Ich hab dabei noch immer nicht zu 100% verstanden, wie dieses LVM-Thin genau funktioniert, speziell hinsichtlich Write-Amplification, falls ein CoW-FS in den Guest kommt.
- Wohin speichern die Snapshots eigentlich? Zwecks Aufteilung des Mirrors...

An Diensten wäre folgendes geplant:
- Cloud (Nextcloud?), als TrueNAS App? Wahrscheinlich nicht ideal, diese Dienste in der Filer-VM laufen zu lassen, aber in dem Fall vllt. der bessere/einfachere Weg?
- Backup (Urbackup?), ebenso als TrueNAS App? Soll ausf Z1 schreiben... also insofern wsl. auch so?
- HomeAssistant, ist ja eher harmlos, also auch im TrueNAS laufen lassen, oder doch direkt am Host? Hmh...
... tja, wer weiss, was noch (Video-Stream per Hardware-En/De-Coding ist keins geplant).

NAS - eher informativ und nicht Kern der Frage:
In den x16 Slot des B550 Boards kommt ein 2x M.2 + PCIe x8 Riser, dieser wird mit dem 9400-16i bestückt.
Per PCIe Passthrough gehen diese 3 Devs in dem Slot (2x 4ty Fura Renegade + 9400-16i) an die TrueNAS VM. Somit hab ich in dieser TrueNAS VM alle Datenträger (bis auf das OS selbst) per PCIe-Passthrough.
Am 9400-16i hängen ein paar 20tb HDDs (bilden mit den 2x 4tb Fury Renegade als svdev Mirror ein Fusion-Z1) und 1-2x 4tb 870-EVO (momentan single, soll aber ein Mirror werden, möchte da meinen Cloud-Speicher einrichten, so dachte ich) und 1x 1tb PM883 für die "Apps" (hätte noch ne 250er PM893 über, könnte ggf. nen 250gb Mirror machen aus den beiden, wobei ich bei dem Drive keine Angst vor Ausfall habe...).
NIC gibts entweder per PCIe Passthrough die Onboard, ne USB oder einfach nur ne Bridge bzw. virtio oder so... bin da unschlüssig, ist bei 2.5 Gbit wohl aber nicht so das Thema (ich spitze drauf später mal ne 10GbE NIC über den USB-C-20G dran zu machen).


Ich muss immer wieder an die Aussage denken, dass in so einem Fall ein Bare-Metal TrueNAS schlau wäre und ein extra V-Host auf sparsamer Intel Hardware (ohne ECC, womit ich wohl sogar leben könnte).
Ich hab mir aber das All-In-One Ding ein bissl in den Kopf gesetzt, am Ende sollte das doch sparsamer und kompakter sein.


So, eigentlich sind nur die kursiven Fragen wichtig. Manche davon sind vllt. bissl komisch, trotzdem konnte ich das trotz intensiver Auseinandersetzung mit dem Thema nicht restlos klären.
Wäre super, wenn ihr da etwas schlaues für mich wisst.

 

[KurantRubys]

An die Docker-Nutzer, habt ihr Docker in eine VM (oder gar mehrere) ausgelagert oder "in" Proxmox direkt installiert?

Rocky Linux VM, direkt auf dem Host widerspricht ja dem Sinn des ganzen Proxmox Hosts vollständig und LXC ist auch nicht optimal. Bzw. hab ich noch einen LXC mit Altlasten, die Dienste sollen aber bald™ auf den VM Host umziehen

 

[gea]

Ich halte ja ESXi immer noch die Treue, überlege mir aber wie ich für einen Wechsel ESXi Funktionalitäten auf Proxmox abbilde, z.B mit VMs auf ZFS.

Mit ESXi kann ich einen konsistenten ESXi Snap (hot memory oder quiesce mit vmware tools) anlegen, dann einen inkonsistenten ZFS snap der den ESXi Snap enthält.Den ESXi snap kann ich dann löschen. Für ein Restore stelle ich den ZFS Snap wieder her und mache dann ein ESXi rollback auf den konsistenten ESXi snap. Das erlaubt normale ZFS snaps und Replikationen für backup und restore ohne das die VM nach restore beschädigt sein könnte.

Gleiches scheint auch unter Proxmox möglich zu sein, sofern man die VM auf ZFS ablegt und den QEMU-Guest-Agent nutzt der ähnliche Funktionen für ein VM freeze hat wie die vmware tools. Man muss lediglich beachten dass ESXi alle Konfigurationsdateien im VM Ordner mit ablegt, während Proxmox diese separat in /etc/pve/* ablegt.

Möglicher Ablauf für ein rein ZFS basiertes backup/restore in Proxmox

- einen konsistenten Proxmox Snap anlegen (Proxmox gui oder cli)
- einen ZFS Snap anlegen der eine aktuelle /etc/pve/* enthält
(manuell bzw habe ich gerade in napp-it autosnap eingebaut)

der ZFS snap selber ist inkonsistent wie nach einem poweroff

Diesen Snap dann per zfs replikation sichern oder als snap versionieren

Für ein restore

- ZFS dataset der VM wiederherstellen (rollback oder replikation)
- zugehörige /étc/pve/* wiederherstellen
- Proxmox neu starten oder config neu einlesen
- in Proxmox auf den konsistenten Snap zurückgehen

Ist mein Gednkengang ok?

 

[Supaman]

@pwnbert
Der SSD Wearout bei ZFS ist nicht ohne. Ich hatte auf einem System normale Consumer SSDs als ZFS-Raid1 für das PVE OS laufen, die waren nach 3 Jahren auf 12% runter.

Die Frage wäre also: willst Du / brauchst Du zwingend Ausfallsicherheit ?

Ansonsten wäre Single Drive + internes Backup sinnvoller.

Als Backup wäre meine Empfehlung der Proxmox Backup Server.

 

[gea]

Hier die eigentlichen Fragen:
Wie mach ich das am besten bei der Einrichtung?
- Wie groß macht man den Speicherplatz fürs Proxmox selbst?

kommt auf die Anzahl der VMs und isos an die man darauf ablegen möchte

- Nimm ich ZFS oder vllt. doch Ext4? So aktuelle Backups brauch ich eigentlich nicht, die VM Sache selbst nicht nicht soo wichtig, wirklich wichtig ist eigentlich nur das NAS. Die Frage zielt etwas auf Write-Amplification ab, sollte bei der Heimanwendung ja nicht so das Thema sein, aber trotzdem... ich bin mir nicht sicher, ob in dem Fall ZFS so der wahnsinnge Vorteil ist, oder ob ext4/xfs nicht voll okay wäre.... hm.

die Wahl ext4Z/ZFS hat man nur für die Proxmos Systemplatte, TN ist ZFS only
Ich würde jedoch immer ZFS bevorzugen wegen CoW (kein kaputtes Dateisystem nach crash) und immer verifizierte Daten aus Prüfsummen, dazu ZFS Snaps

- Eine Micron 7400pro mit PLP hätte ich noch, ggf. als SLOG fürs ZFS denkbar, wenn man damit die Schreiblast wirklich merklich reduzieren würde... bin da auch noch nicht zu 100% dahinter gekommen, wie sich nun ein Non-PLP-VDEV mit einem PLP SLOG verhält... das Ding verbraucht doch 7W, wenn sinnlos ist, bleibts draußen.

Ein Slog schreibt Daten mit aktiviertem sync sofort nach einem commit damit man das nach einem Crash beim reboot wiederherstellen kann. Wenn man sync ohne slog aktiviert, macht man dieses logging auf den Pool. Der schreibt dann die im ram schreibache gesammelten daten zusätzlich mit Verzögerung. Ein Slog halbiert also die Schreiblast auf den Pool bei aktiviertem sync.

- Für die VMs dann LVM-Thin?

oder ZFS stattdessen

Ich hab dabei noch immer nicht zu 100% verstanden, wie dieses LVM-Thin genau funktioniert, speziell hinsichtlich Write-Amplification, falls ein CoW-FS in den Guest kommt.

Thin bedeutet dass der Platzverbrauch auf Platte dynamisch zugewiesen wird. Write Amplification hat damit nicts zu tun.

- Wohin speichern die Snapshots eigentlich? Zwecks Aufteilung des Mirrors...

ZFS Snaps sind keine Kopien sondern der Datenstand vor der lethten Änderung. CoW bedeutet ja dass keine Daten überschrieben sondern immer neu geschrieben werden

An Diensten wäre folgendes geplant:
- Cloud (Nextcloud?), als TrueNAS App? Wahrscheinlich nicht ideal, diese Dienste in der Filer-VM laufen zu lassen, aber in dem Fall vllt. der bessere/einfachere Weg?
- Backup (Urbackup?), ebenso als TrueNAS App? Soll ausf Z1 schreiben... also insofern wsl. auch so?

Backup in ZFS basiert immer auf zfs send, egal welche Software

 

[Kavendish]

Rocky Linux VM, direkt auf dem Host widerspricht ja dem Sinn des ganzen Proxmox Hosts vollständig und LXC ist auch nicht optimal. Bzw. hab ich noch einen LXC mit Altlasten, die Dienste sollen aber bald™ auf den VM Host umziehen

Hintergrund ist halt ich habe derzeit 3 VM. 1x Debian auf dem kleinen 24/7 Prox mit verschiedenen Microservices die 24/7 nötig sind. Eine zweite Debian VM auf dem kleinen 24/7 mit eher on-demand-Geschichten, die aber nur Inhalte des kleinen SSD-Pools benötigen. Dann gibt es halt noch eine monothematische Ubuntu-VM auf dem großen System, wo halt die ARC310 und HDD-Pool gebraucht werden, aber gesamte Rechner ist halt selten an.

Irgendwie gefällt es mir halt nicht, daher wollte ich wissen wir ihr Docker auf Promox-Hosts so handhabt.

 

[pwnbert]

kommt auf die Anzahl der VMs und isos an die man darauf ablegen möchte

Ich mein das eher anders rum, wie viel soll für Proxmox (also das OS selbst) bei der Installation partitioniert werden?

die Wahl ext4Z/ZFS hat man nur für die Proxmos Systemplatte, TN ist ZFS only

Auf das wars auch bezogen.

oder ZFS stattdessen

Ja, aber mit ZFS drunter hab ich ja ne gewisse Write Amplification, die mitunter nicht ohne ist, mh?

Thin bedeutet dass der Platzverbrauch auf Platte dynamisch zugewiesen wird. Write Amplification hat damit nicts zu tun.

Das versteh ich schon.
Wenn ich jetzt für ne VM "ein Stück" vom LVM Thin zuweise und das in der VM entsprechend als Ext4 oder ZFS formatiere, dann ist das Filesystem direkt "raw" auf dem LVM? Also ohne einem CoW darunter.
Muss z.B. qcow2 extra ausgewählt werden, oder sind die zugewiesenen "Stücke" vom LVM-Thin automatisch ein qcow2 (oder sowas)?

Die Frage ist vllt. komisch, aber... nunja.

ZFS Snaps sind keine Kopien sondern der Datenstand vor der lethten Änderung. CoW bedeutet ja dass keine Daten überschrieben sondern immer neu geschrieben werden

Mhja, eh, schlecht formuliert. Der Verbrauch an Speicherplatz ist dann entsprechend größer, als "offensichtlich" drauf liegt.
=> Faustregel zur "Überdimensionierung"? Ich weiss, hängt bestimmt sehr von den Gegebenheiten ab.. aber irgendwo muss man ja anfangen.

Der SSD Wearout bei ZFS ist nicht ohne. Ich hatte auf einem System normale Consumer SSDs als ZFS-Raid1 für das PVE OS laufen, die waren nach 3 Jahren auf 12% runter.

Wie viel hat das System "gearbeitet"?
Consumer-SDD ist ein recht dehnbarer Begriff, die KC3000 / Fury Renegade haben relativ viel TBW (sicher 10x so viel wie so Billigkram) und gar nicht sooo viel weniger als RI-Datacenter-SSDs.
Als SVDEV im Z1 Fusion hab ich sie schon länger laufen, die TBW dort sind sehr überschaubar.

Ist halt die Frage, ob ich ein ZFS auf wenig Wearout hintunen will oder einfach ein ext4 oder xfs mach... mh...

Die Frage wäre also: willst Du / brauchst Du zwingend Ausfallsicherheit ?

Haja, nein, aber Faulheit und so.
Die 2 SSDs sind schon da (hab die letztes Jahr ziemlich günstig gekauft), man kann ja auch einen ext4/xfs "Mirror" (LVM Raid 1) machen, so ists ja nicht... dafür müsste ich zwar erst nachsehen, wie man das in diesem Fall am besten anstellt, aber ich bin mir sicher, dass das kein großes Problem sein kann.

Als Backup wäre meine Empfehlung der Proxmox Backup Server.

Das ist dann ohnehin ne eigene Geschichte.

 

[BobbyD]

@pwnbert Ich hab z.B. teilweise Sync-Writes abgeschaltet, um der Write Amplification entgegen zu wirken. Wenn Du ZFS nimmst, musst Du dich bei Proxmox auch nicht entscheiden, wie groß welche Partition sein soll, weil da nicht nach dem Einsatzzweck unterschieden wird, meine ich. Und Swap gibt es erstmal auch nicht, was auch kein Problem ist, wenn man genug RAM hat. So zumindest mein Stand.

 

[layerbreak]

Möglicher Ablauf für ein rein ZFS basiertes backup/restore in Proxmox

- einen konsistenten Proxmox Snap anlegen (Proxmox gui oder cli)
- einen ZFS Snap anlegen der eine aktuelle /etc/pve/* enthält

Und nur die zu sichernde Einstellungen, aus /etc/pve/, dieser VM in das Verzeichnis worin die VM liegt, vorher rein kopieren.
So kann nix schief gehen bei einem Restore - wo dann die Einstellungen der anderen VMs eventuell überschrieben werden.

 

[gea]

Es ist wie immer ein Zielkonflikt

- VMs auf ZFS ohne sync die kein ZFS nutzen, können nach einem Absturz ein defektes Dateisystem haben.
Sync schützt. Man muss halt SSD mit mehr Schreiblast nehmen oder ein extra Slog oder die SSD früher erneuern oder das Problem in Kauf nehmen.

- Bootdisk mit VMs oder kleine Bootdisk nur für OS und extra Datenpool
ersteres ist billiger, man muss halt bei Neuinstallation aufpassen und ein physischer Pool Move geht nicht.
> Ich würde immer OS und ZFS Datenpool auf physischen Platten trennen. Partitionieren für OS und ZFS Datenpool machts nur komplizierter.

- Das ZFS Dateisystem hat wegen Copy on Write eine etwas höhere Write Amplification kann dafür nach einem Crash beim Schreiben nicht kaputtgehen., letzteres wäre mir wichtiger. Eine VM deren Systemplatte als zvol auf ZFS liegt, ist nicht so das Problem. Nur wenn man ZFS ontop ZFS macht z.B. ein filebasiertes ZFS iSCSI target auf einem ZFS Pool wirds etwas unangenehmer. Aber auch hier gilt wie oft, will man gut oder billig und bei gut gibts auch billige gebrauchte Enterprise SSDs?

Beitrag automatisch zusammengeführt: Gestern um 19:34

Und nur die zu sichernde Einstellungen, aus /etc/pve/, dieser VM in das Verzeichnis worin die VM liegt, vorher rein kopieren.
So kann nix schief gehen bei einem Restore - wo dann die Einstellungen der anderen VMs eventuell überschrieben werden.

Nur wenn man VMs auf verschiedene Orte verteilt, muss man darauf achten dass man beim Restore nur die Einstellungen der VMs aus dem Snap wiederherstellt. Besser ist es alle VMs auf ein ZFS Dateisystem zu legen. Dann ist ein Snap mit der /etc/pve/* Kopie für alle VMs im Snap gültig und man muss nichts beachten.

 

[layerbreak]

Nur wenn man VMs auf verschiedene Orte verteilt, muss man darauf achten dass man beim Restore nur die Einstellungen der VMs aus dem Snap wiederherstellt. Besser ist es alle VMs auf ein ZFS Dateisystem zu legen. Dann ist ein Snap mit der /etc/pve/* Kopie für alle VMs im Snap gültig und man muss nichts beachten.

Dann habe ich dich vermutlich missverstanden.

Ich bin von deinem AIO Prinzip von früher ESXi ausgegangen.
Da sind immer alle VMs auf einem Pool gelegen. Jede VM hatte ihre Einstellungen im VM-Verzeichnis drinne.
Bei Proxmox liegen aber diese Einstellungen ALLER VMs in einem einzigen Verzeichnis.

Jetzt hab ich dich so verstanden, dass Du einen Snapshot vom VM xy erstellen möchtest und dann auch den gesamten Inhalt von /etc/pve/ mit in diesen Snapshot "packst".
Mein Gedanke war jetzt, nicht die Einstellungen aller VMs, sondern nur die Einstellungen von VM xy in den Snapshot vorher zu kopieren.

So kann nix passieren im Falle eines "restores" bei den unbeteiligten VMs.

 

[gea]

Bei ESXi gibts je VM einen Ordner mit den filebasierten virtuellen Platten mit deren Snaps und der .vmx Konfigurationsdatei darin. Da hat man nach backup/restore des Ordners alles was man braucht.

In Proxmox und ZFS ist eine Platte einer VM ein zvol auf dem ZFS Pool. Für jede VM gibts extra eine Konfigurationsdate z.B. /etc/pve/nodes/pve/qemu-server/100.conf. Die entspricht in etwa der .vmx aus ESXi. Für ein restore brauchts da die zvols auf dem ZFS Pool und z.B. die /etc/pve/nodes/pve/qemu-server/100.conf

 

[layerbreak]

Ich halte ja ESXi immer noch die Treue, überlege mir aber wie ich für einen Wechsel ESXi Funktionalitäten auf Proxmox abbilde, z.B mit VMs auf ZFS.

- einen konsistenten Proxmox Snap anlegen (Proxmox gui oder cli)
- einen ZFS Snap anlegen der eine aktuelle /etc/pve/* enthält

Ist mein Gednkengang ok?

Das war doch die Ausgangslage.
Ich verstehe es so, dass du, wegen des Sternchen, den kompletten Inhalt von /etc/pve/ mit in den Snap legen möchtest.

In Proxmox und ZFS ist eine Platte einer VM ein zvol auf dem ZFS Pool. Für jede VM gibts extra eine Konfigurationsdate z.B. /etc/pve/nodes/pve/qemu-server/100.conf. Die entspricht in etwa der .vmx aus ESXi. Für ein restore brauchts da die zvols auf dem ZFS Pool und z.B. die /etc/pve/nodes/pve/qemu-server/100.conf

Mein Gedankenanstoß war jetzt:
Es soll ein Snap der VM100 angelegt werden.
Anstatt den kompletten Inhalt nur die 100.conf in den Snap zu packen - damit bei einem späteren Rückschritt auf diesen Snap nicht irrtümlicherweise der komplette Inhalt, sondern nur die 100.conf in /etc/pve/ rückkopiert wird.

Hoffe ich habe mich jetzt verständlicher ausgedrückt.

 

[gea]

In meinen Autosnap Jobs sichere ich als Joboption den kompletten aktuellen /etc/pve/* Inhalt auf das Dateisystem von dem der Snap erstellt wird in einen Ordner _include via rsync. Zum Wiederherstellen kann man manuell die benötigten Dateien zurückkopieren z.B. nur die 100.conf

 

[Supaman]

Bitte beachten: eine Proxmox VM besteht nicht nur aus der <vm-id>.conf , einer oder mehrerer (HDD) Disks, sondern kann auch noch für Uefi und TPM weitere Disks beinhalten, die nicht zwingend auf dem dem selben Storage liegen müssen, wo die Main Disk liegt.

 

[gea]

Eventuelle uefi und tpm Disks sind mit ZFS doch auch zvols auf dem ZFS Pool

Quelle Gemini:
Du kannst VMs in einem ZFS-Dataset wie tank/data oder einem Pool anlegen, aber der Prozess ist etwas anders,
je nachdem, wie du diesen Datensatz in Proxmox konfigurierst. Proxmox unterstützt ZFS-Speicher auf zwei Hauptarten:
als ZFS-Pool oder als Verzeichnis (Directory).

ZFS-Pool (Block-Speicher)
Dies ist die empfohlene Methode für VMs.
Wenn du einen ZFS-Speicher in Proxmox erstellst, gibst du als pool den Pfad zum Dataset an, also tank/vms.

Proxmox erstellt dann direkt in diesem Dataset ZFS-Volumes (ZVOLs) für jede VM-Disk.

Die ZVOLs sind Block-Geräte.
Die Benennung der ZVOLs erfolgt weiterhin nach dem Schema tank/vm-101-disk-0, da Proxmox die Disks auf Poolebene verwaltet, auch wenn sie in einem untergeordneten Dataset liegen.

Verzeichnis (Datei-Speicher)
Du kannst das Dataset tank/vms auch als Verzeichnis-Speicher in Proxmox hinzufügen.

Proxmox speichert die VM-Disks dann als Dateien (z.B. .qcow2 oder .raw) in diesem Verzeichnis.

Der Pfad zu den VM-Dateien würde dann so aussehen: /tank/vms/images/101/vm-101-disk-0.qcow2.

Diese Methode hat den Vorteil, dass du verschiedene Dateiformate nutzen kannst,
verlierst aber die direkten ZFS-Vorteile wie Instant-Snapshots und Thin-Provisioning auf Block-Ebene.

Man muss daher beim Setup etwas aufpassen und einen ZFS Pool z.B. tank/vms nehmen.
Da mit recursiven Snaps, rollback, replication oder clone arbeiten.

Für das Restore brauchts halt die .conf und alle Platten der VM.
Mit zfs list kann man aber schnell ermitteln, welche das sind