[Sammelthread] Proxmox Stammtisch

Ich halte bei PVE die Proxmox-SSD(s) und VM/Datendevices grundsätzlich getrennt, solangs nicht nur ein Experimentieraufbau ist.
Grund: Flexibilität. Im Zweifelsfall: System-SSD raus, neue rein, PVE installieren, Zpool mit den VMs/Daten importieren sowie Configdateien wieder reinkopieren und weiter gehts.

Der übrige Speicher System-SSD wird halt durch die benötigten ISOs oder Templates benutzt. Ausserdem ist dann genug freier Platz mit genug frischen Zellen da um Logwrites aufzunehmen; sprich SSD hält lange.

Im Prinzip nutz ich meine vorhandenen kleineren Gen3 PCI-SSDs (Samsung 970evo Plus 1TB) immer für sowas (da zu klein geworden für die Windowsrechner oder ZPools und zeigten nie Ausfälle).
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Grund: Flexibilität. Im Zweifelsfall: System-SSD raus, neue rein, PVE installieren, Zpool mit den VMs/Daten importieren sowie Configdateien wieder reinkopieren und weiter gehts.
So viel anders läuft das doch aber bei einer einzelnen Disk auch nicht... man wird die VMs ja irgendwo sichern. Für den Heimeinsatz sehe ich das daher eher entspannt.
 
Handhabe ich auch schon seit längerer Zeit so: Host hat seinen Datenträger, Filer auch einen direkt am Board, und VMs durchgereicht am HBA.
 
So viel anders läuft das doch aber bei einer einzelnen Disk auch nicht...
Naja, nicht ganz.
Wenn du die "Daten" extern hast, musst du diese erstmal ins System laden und das dauert.
Wenn das getrennt ist, sind die "Daten" bereits im System und müssen lediglich "gemountet" werden und los gehts.
Das eine dauert 10sec nach laufendem Reinstall des Hypervisors, das andere dauert ggf. Stunden, je nach Größe und Bandbreite.
 
Oder, man umgeht das Problem "langsamer Restore" mit einem 25GbE-Netzwerk und Backup der VMs auf NVMe-Storage. Für Heimanwender teuer? JA! Irgendwie sinnlos? JA! Trotzdem geil? JAA! :d
Meine größte Einzel-VM mit 200 GB braucht vom PBS so ca. 2 Minuten für einen Restore, kann ich mit leben.
 
Hier mal ein Update zu meiner PVE Sicherung mit PBS. Leider etwas spät meine Rückmeldung, mich hatte es ganz schön erwischt gehabt.
Bin aber immer noch nicht ganz fit, daher nur eine Zusammenfassung.

Also ich habe den PBS als VM aufm PVE installiert und den PBS mit dem NFS Share des NAS (TrueNAS) verbunden (direkt über die fstab des PBS). Für die erste Erstellung dieser "Chunks" oder wie die heißen, musste ich den User "Root" sowie die Gruppe "Wheel" für die NFS Freigabe freischalten (Maproot user und Maproot Group heißt das bei TrueNAS). Nachdem das erste Backup durch ist, konnte ich das wieder deaktivieren, da PBS dann alle mit dem User "Backup" mit der UID "34" macht. Dieser ist auch standardmäßig bei TrueNAS Scale schon vorhanden.

Die Backups laufen jede Nacht problemlos durch, der Deduplication Factor liegt aktuell bei 19,51.


Die PBS VM selbst (das Image) habe ich dann normal per Backupfunktion als Image gesichert und dieses einfach per temprärer NFS Freigabe aufs NAS kopiert.
Sodass es bei einem Ausfall der SSD nur einer Neusinstallation von PVE bedarf, in das ich dann das PBS VM Image zurückspiele und damit direkt wieder Zugriff auf alle Backups habe.
 
Ich halte bei PVE die Proxmox-SSD(s) und VM/Datendevices grundsätzlich getrennt, solangs nicht nur ein Experimentieraufbau ist.
Grund: Flexibilität. Im Zweifelsfall: System-SSD raus, neue rein, PVE installieren, Zpool mit den VMs/Daten importieren sowie Configdateien wieder reinkopieren und weiter gehts.

Der übrige Speicher System-SSD wird halt durch die benötigten ISOs oder Templates benutzt. Ausserdem ist dann genug freier Platz mit genug frischen Zellen da um Logwrites aufzunehmen; sprich SSD hält lange.

Im Prinzip nutz ich meine vorhandenen kleineren Gen3 PCI-SSDs (Samsung 970evo Plus 1TB) immer für sowas (da zu klein geworden für die Windowsrechner oder ZPools und zeigten nie Ausfälle).

Du nutzt "normale" SSD's (ohne PLP) für die VM's?
Gibt's da keine Probleme mit erhöhtem Verschleiß wegen ZFS?


Danke!

LG
 
Neben dem normalen erhöhten Verschleiß bei Nutzung mit ZFS und dann auch noch in Verbindung von VM`s kann das bei einem Stromausfall vor allem dafür sorgen das man korrupte Daten hat und so ein ZFS bzw. eine VM dann nicht mehr startet. Gibt dazu genug im Proxmox Foren zu finden. Man sollte schon auf Enterprise zurückgreifen, da hier bei einem Stromausfall oder eben bei dem Versagen der UVS die Daten kurz gepuffert werden innerhalb der SSD und die Daten dann noch i.O. sind. Ich selbst hatte aber bis jetzt noch keinen Ausfall, somit plapper ich auch nur die offiziellen Meldungen runter ;-)
 
Und dennoch hat das eine nichts mit dem anderen zu tun. Außer man geht der Annahme nach SSD mit PLP höherwertig als welche ohne PLP. Aber dennoch, zwei paar Schuhe. Zumal PLP unabhängig von dem Dateisystem ist.
Beitrag automatisch zusammengeführt:

Du nutzt "normale" SSD's (ohne PLP) für die VM's?
Ich mache das - wenn auch mit einer Optane als Slog Device.
Private Nutzung wohlgemerkt, wo der Betrieb nicht geschäftskritisch ist.
 
Zuletzt bearbeitet:
Neben dem normalen erhöhten Verschleiß bei Nutzung mit ZFS und dann auch noch in Verbindung von VM`s kann das bei einem Stromausfall vor allem dafür sorgen das man korrupte Daten hat und so ein ZFS bzw. eine VM dann nicht mehr startet. Gibt dazu genug im Proxmox Foren zu finden. Man sollte schon auf Enterprise zurückgreifen, da hier bei einem Stromausfall oder eben bei dem Versagen der UVS die Daten kurz gepuffert werden innerhalb der SSD und die Daten dann noch i.O. sind. Ich selbst hatte aber bis jetzt noch keinen Ausfall, somit plapper ich auch nur die offiziellen Meldungen runter ;-)

Ein Copy on Write Dateisystem zumal mit Prüfsummen schreibt etwas mehr Daten als "alte" Dateisysteme. Eine ganz "billige" Desktop SSD muss man dann eventuell etwas früher erneuern. Mehr Probleme gibts nicht außer der geringeren realen Performance im Vergleich zu Datacenter SSD.

In einem Raid werden Datenblöcke auf den verschiedenen Platten nacheinander geschrieben. Bei einem Absturz beim Schreiben können ohne plp defekte Datenblöcke entstehen, genau wie durch ssd garbage collection im Hintergrund. Da ZFS diese defekten Datenblöcke sicher erkennen (Prüfsummen) und aus Redundanz reparieren kann, ist das ziemlich unkritisch. Durch Copy on Write ist das Risiko eh sehr klein.

Will oder muss man bestätigte Schreibaktionen absichern (VM Storage), so kann man sync logging aktivieren. Fehlende Writes bei einem Absturz werden dann beim nächsten Reboot nachgeholt. Hier ist es jedoch kritisch, dass ein Slog plp kann, sonst kann das log bei einem Absturz korrupt sein. Ein Slog Mirror hilft auch, ideal ist ein slog mit plp.

Intel garantiert bei den teureren Optane plp. Aber auch bei den billigeren ohne plp im Datenblatt, ist man normalerweise auf der sicheren Seite.
 
Hab mir nun einen eigenen PBS gegönnt, statt den neben dem PVE installiert zu haben. 😉

Screenshot 2026-01-10 175910.png
 
Zuletzt bearbeitet:
Ich bräuchte mal euer Schwarmwissen.
Habe hier folgende Consumer-Hardware:

Intel Pentium Gold G6400
ASRock B460M ITX/AC
2x 4GB Corsair Vengeance 3000
Kingston A2000 m.2 NVMe 250GB
250W Flex-ATX Netzteil

Darauf lief Jahre lang mehr oder minder gut OMV (ohne große Abstürze, aber manchmal war ein Neustart fällig, weil die Oberfläche nicht erreichbar war), 2 normale HDDs als JBOD, wo die eine auf die andere per RSYNC die Daten gebackuped hat.
Auf den Festplatten liegen keine wichtigen Sachen, es diente oft nur dazu, auf dem Fernseher die gemachten Aufnahmen abzuspielen.

Vor Weihnachten wollte ich OMV dann platt machen und auf Proxmox gehen, weil ich nebenbei noch Home Assistant OS laufen lassen wollte. Also NVMe platt gemacht und Proxmox installiert, lief alles durch. Zudem hatte ich eine VM für Home Assistent eingerichtet. Die Installation brach zwischendurch immer wieder mal ab, wegen korrupten Dateien, das Internet vor Ort ist nicht das beste (10 mbit), irgendwann war aber alles sauber durchgelaufen.
Über Nacht lief dann ein Update durch und danach war die VM auf einmal nicht mehr erreichbar. Lies sich auch nicht mehr neustarten, nach einem Neustart des Rechners hatte es dann auch Proxmox ausgehebelt.

Kein Problem, dachte die NVMe hat es vielleicht hinter sich, also eine WD Red Pro bestellt und eingebaut. Proxmox lässt sich nun nicht mehr installieren, manchmal blieb die Installation bei 70% stehen, manchmal lief es bis 100% durch, dann kam folgende Fehlermeldung:

Code:
command chroot target dpkg --force-confold --configure - a failed with exit code 1 at /usr/share/perl5/proxmox/install.pm line 1338
Getestet wurde an zwei Netzwerkstandorten, Fehlermeldung blieb identisch.

Nun habe ich die Hardware, bis auf die Ram-Riegel und NVME (WD Red Pro) getauscht und das berühmte Gigabyte MJ11-EC1 verwendet.
Installation lief durch, weiter habe ich noch nicht getestet.

Hat jemand eine Idee, warum Proxmox immer wieder ausgestiegen ist? Die alte Kingston NVMe hatte laut CystalDiskInfo noch 98%, hat sehr wenig geschrieben (ich meine 4-5 TB) und über 4 Jahre Betriebsstunden auf dem Buckel. Die Hardware lief 24/7.
 
bis auf die Ram-Riegel
Memtest86? :fresse:

Hast mal ein neues Image geladen und aufn anderen Stick getan (oder wie auch immer du installierst)?
Ich erinnere mich dunkel, dass ich bei irgend einer Distri irgendwann ein Problem mit einem Iso hatte... vielleicht?
Kann ja was älteres sein auch, updatet eh selber.
 
Ich hab das 9.1-1 und ein älteres 8.x getestet. Ebenso zwei USB Sticks.

Ram werde ich mal testen, danke!
 
:fresse:
Tja.

Für mich nur noch ECC.
Beitrag automatisch zusammengeführt:

Nachtrag:

Wsl. waren das auch deine OMV reboots oder was du da hattest.
Hatte auch mal defekten RAM am Desktop, bin da auch erst viel zu spät drauf gekommen (war eig. auch dumm/nachlässig von mir das nicht zu prüfen).
Es ist erstaunlich, wie lange man oft mit defektem RAM arbeiten kann ohne es wirklich zu merken (bzw. ohne es dem RAM zuzuschreiben, das sind dann "komische Bugs von Windows / DistriXYZ")... blöd nur, wenns zu spät ist.

Mag gar nicht wissen, wie viele Gaming-Systeme Memtest nicht schaffen würden... sicher 2-stellige %...


Imho ist ohne ECC zumindest ein Memtest Lauf 1x im Jahr angebracht als "TÜV"... besser als nix.
Imho ist Memtest ja sogar im Proxmox Bootloader dabei, oder? Warum nur. :d
 
Zuletzt bearbeitet:
Ich habe hier noch ECC Ram liegen, muss nur überlegen welche Hardware ich nun nehme. Die alte war schön stromsparend und eigentlich ausreichend.

@BobbyD Gleiches Problem auf 2 verschiedenen Mainboards? Ich kann aber gerne nachher mal gucken, welche Spannung auf dem Asrock anliegt. Hab beide Ram Riegel gerade ausgebaut und gegen einen 16 GB getauscht
 
Zuletzt bearbeitet:
Wie meinst du das mit dem Bind Mount?
Sieht etwa so aus:
1768141566597.png

Wenn ich jetzt den PBS auf dem TrueNAS installieren würde?
Bei mir läuft der als LXC im PVE. "Irgendwie" ähnlich sollte das auch im TN gehen.
Ich aktiviere auch samba bzw ksmbd ...
Mit dem ksmbd hatt ich hier Probleme. Beim Zuzgriff von Windowsclients. Samba geht einwandfrei.
Hat jemand von euch schonmal Synology als VM laufen lassen und hat damit erfahrungen wie gut das funktioniert?
Ich hab den RR-Loader, geht einwandfrei.
Also dann Festplatten in Proxmox durchreichen z.B.
So was mach ich net.
Du nutzt "normale" SSD's (ohne PLP) für die VM's?
Gibt's da keine Probleme mit erhöhtem Verschleiß wegen ZFS?
Ich hab WD SN700, knapp 4 Jahre alt. Waren schon im QNAP und jetzt im MN5 mit PVE als special vdev für den HD-Pool; Via special_small_blocks kommen auch VMs drauf, z.B. ein Windows Server 24/7. Wear level ist bei 15%. >300 TB witten. Also... ich halte das alles für ziemlich übertrieben.
... kann das bei einem Stromausfall vor allem dafür sorgen das man korrupte Daten hat und so ein ZFS bzw. eine VM dann nicht mehr startet.
Hatt ich noch nie. Und es gibt ja zur Not noch Backups. :sneaky:
 
Mit dem ksmbd hatt ich hier Probleme. Beim Zuzgriff von Windowsclients. Samba geht einwandfrei.

ksmbd ist halt deutlich schneller als Samba, war aber in Proxmox 8 buggy
 
Vor dieser "Warnung" habe ich schon öfters gelesen...aber kp in welchen Umständen das auftreten soll...ich nutze privat schon so lange ZFS, und mir ist bisher keine SSD kaputtgegangen.

Hm, vor einiger Zeit mal neue Samsung Evo's für ca. 3 Monate als Übergangslösung in TrueNAS verwendet - hab die Werte nicht mehr auswendig im Kopf, aber die Smart-Daten haben nach 3 Monaten schon deutlich gelitten!

Bei den jetzigen DC-SSD's tut sich nix.

Keine Ahnung, ob es an TrueNAS, oder an ZFS liegt!?
 
Keine Ahnung, ob es an TrueNAS, oder an ZFS liegt!?
Ich denke, es liegt eher an der Nutzung und ggf. auch ob und wenn ja welches RAID Level genutzt wird.
Auch wenn man das vermutlich nicht wirklich vergleichen kann, alleine schon ob der geringen Menge. Ich habe seit 2010 eine Crucial c300 128 GB, diese war nach Jahren von Windows gepeinigt, die Behausung meines Solaris für gut 7-8 Jahre - ich hab mir jetzt zwar nicht ihre Werte angeschaut, aber Ausfälle hatte ich nicht.

Inwiefern das OS ZFS als solches beeinflussen kann (Voreinstellungen etc.) weiß ich nicht, das wäre etwas für @gea, allerdings wenn auch ständig Logs geschrieben werden durch Dienste etc … kann das schon einen Einfluss haben.
 
Ich denke, es liegt eher an der Nutzung und ggf. auch ob und wenn ja welches RAID Level genutzt wird.
Auch wenn man das vermutlich nicht wirklich vergleichen kann, alleine schon ob der geringen Menge. Ich habe seit 2010 eine Crucial c300 128 GB, diese war nach Jahren von Windows gepeinigt, die Behausung meines Solaris für gut 7-8 Jahre - ich hab mir jetzt zwar nicht ihre Werte angeschaut, aber Ausfälle hatte ich nicht.

Inwiefern das OS ZFS als solches beeinflussen kann (Voreinstellungen etc.) weiß ich nicht, das wäre etwas für @gea, allerdings wenn auch ständig Logs geschrieben werden durch Dienste etc … kann das schon einen Einfluss haben.

Liefen in Raid Z1 ohne großer Last – da werden nur alle paar Tage mal Fotos von den Handys gesichert.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh