[Sammelthread] Proxmox Stammtisch

Wenn du wie in meinem Link beschrieben die beiden pve Dienste deaktivierst, kannst du ZFS auch auf root laufen lassen. Ist ja sogar Default. Habe ich ja auch so an laufen auf zwei EVO 850 (seit 2014 haben die einen wearout von 22 %. Damals konnte ZFS auch noch kein trim)

Zum Journald und syslog: gerade bei Testkisten sollte es aktiviert bleiben, sonst bekommst du keine fehlerlogs mehr angezeigt.

Warum ich nach einem HBA fragte: da braucht man für trim SSDs, die DRAT oder RZAT unterstützen. Da du keinen HBA nutzt, ist das irrelevant für dich.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Zum Journald und syslog: gerade bei Testkisten sollte es aktiviert bleiben, sonst bekommst du keine fehlerlogs mehr angezeigt.
Vielen Dank für die Info. Wenn das alles ist, glaub ich, wenn das mir wearout erspart, würde ich die nur bei Bedarf aktivieren / starten. Ich erwarte das Ding 24/7 laufen zu lassen und nur alle 2 Wochen mal was auszuprobieren...
 
Gegen ZFS spricht nichts ;), außer dass das Copy on write schon etwas mehr Schreiblast erzeugen dürfte?

So oder so ein regelmäßiges TRIM vorsehen und möglichst etwas mehr Ober-Provisioning machen (zB via Host protected area), das hilft jeder SSD. und die pro sollte auch etwas resistenter gegen wearout sein.
 
Wie gesagt, ich habe seit 2014 EVO 850 in meinem Server, die aktuell 22% wearout haben. Diese liefen immer 24/7. Und dabei gibt es erst seit wenigen Jahren Trim für ZFS on Linux. Danach hinzugefügt SSDs haben zwischen 1 und 11 % wearout nach mehreren Jahren 24/7 Betrieb.
Ich habe dabei nie over-provisioning eingestellt und nie syslog oder Journald deaktiviert. Erst vor 2 Jahren habe ich die beiden pve Dienste deaktiviert, was die Schreiblast deutlich reduzierte.

Trim brauchst du dich nicht drum zu kümmern, das macht proxmox automatisch einmal pro Woche und scrub einmal pro Monat.
 
Das einzige, was du deaktivieren solltest, ist pve-ha-lrm und pve-ha-crm. Das wird nur für Cluster benötigt und schreibt regelmäßig.
Danke für den Tipp, hab ich bei mir auch gleich gemacht. Bei mir sind auch Consumer SSDs drin, hab aber tatsächlich noch nicht drüber nachgedacht da irgendwas zu deaktivieren.
 
Und ZFS hat mit LZ4 oder ZStandard gute und schnelle Kompressionsverfahern drin, die das COW teilw. ausgleichen.

Man sollte halt nicht irgendwelche kleinen Billo-SSDs oder welche mit QLC für Proxmox Systemlaufwerke nutzen, die nur niedrige TBW haben und nix aushalten.
Gute obere Mittelklasse oder Oberklasse (wie die 850/60/70 Evo) dürften schon ne Weile halten.

Mein kleiner Proxmoxserver hat das System z.b. auf einer 970EvoPlus 1TB (@ ZFS, wird noch zu einem Mirror erweitert werden, dazu muss ich erst ne andere SSD freimachen) ,
die VMs liegen auf einem ZFS Mirror Pool (aus SN850 2TB).
Der größere Server, den ich evtl. auf Proxmox umstelle (heute ESXI 7 mit BSD 11 als ZFS Storage-VM) hat eh zwei PM9A3 im Mirror für die VMs. Mit Proxmox ist die Idle Leistungsaufnahme etwa 10-15W niedriger als mit der ESXI+BSD Variante.


Btw, Frage als Proxmox-Anfänger: kann man sich (und wenn ja: wie) ein Configfile (XML, Json, whatever) erzeugen, welches die ganzen Konfigurationen beinhaltet und ich bei einer Neuinstallation einfach zurückspielen kann und alles bis auf die Datenpools/VM-Images wieder da ist? Bei ESXI geht das ja (Neu installieren, config einlesen, VMs einhängen, ready to go).
Oder geht Config-Backup nur über den Proxmox-Backup-Server?
 
Zuletzt bearbeitet:
Btw, Frage als Proxmox-Anfänger: kann man sich (und wenn ja: wie) ein Configfile (XML, Json, whatever) erzeugen, welches die ganzen Konfigurationen beinhaltet und ich bei einer Neuinstallation einfach zurückspielen kann und alles bis auf die Datenpools/VM-Images wieder da ist? Bei ESXI geht das ja (Neu installieren, config einlesen, VMs einhängen, ready to go).
Oder geht Config-Backup nur über den Proxmox-Backup-Server?
Einfach /etc/pve/ sichern ;)
 
Also ich hab auf meinem proxmox auch ein TrueNAS laufen. Onboard HBA ist durchgereicht an die TrueNAS VM, ebenso die Hälfte einer Intel NIC 520, die andere Hälfte nutzt das proxmox selber. Ich hab weitere VMs am Laufen mit weiteren / anderen PCIe Karten, die habe ich ohne Probleme durchreichen können - keine Ahnung was hier "out of the Box" heißen soll...
Ich persönlich habe 2 Intel DC SSD, eine für proxmox und eine für "wichtige" VMs, und "unwichtige" VMs mit Speedbedarf hängen auf einer PCIe-M.2-SSD-Karte...


Edit: Aaaa okay das ist gemeint @MisterY - das ist sooo lange her bei mir, ganz vergessen ;)


Angeblich muss man hierfür einige Dinge manuell in der Kommandozeile "herummurxen"!?

Out of the Box heißt für mich, dass dieses Feature fix integriert ist und via grafischer Oberfläche einfach "genutzt" werden kann.
 
Angeblich muss man hierfür einige Dinge manuell in der Kommandozeile "herummurxen"!?
Na ja, sowas wie iommu aktivieren ist halt plattformspezifisch und eine Kerneloption. Daher gibt es da auch keine Klickibunti Option für.

Alle Klickibunti Settings werden in /etc/pve/ gespeichert. Aber sowas wie die Kernel cmdline Parameter sollte man lieber nicht über die GUI bearbeiten, da im schlimmsten Fall dann das System einfach nicht mehr bootet. Daher verstehe ich auch die Entscheidung der Proxmox Entwickler dies nicht direkt über die GUI zugänglich zu machen, da man hier wissen sollte was man tut.

Ist IOMMU aber einmal aktiviert, dann ist der PCI-Passthrough selbst problemlos über die GUI möglich.
 
Uhm ganz ehrlich: Wenn man einen Virtualisierer einsetzt sollte man keine Angst vor der Konsole haben!

Mal nen anderes Thema:
Proxmox auf SDD installiert, dazu gibts eine weitere SDD und 4 HDDs. Die HDDs sind ein zraid-pool. Auf dem proxmox sind mehrere VMs, unter anderem auch eine die Dinge aus dem Internet herunterlädt und eine weitere die diese Dinge als rsync server mehreren clients zur Verfüung stellen soll. Also VM1 schreibt und liest, VM2 stellt lesend zur Verfügung. Ich würde ungern die Daten duplizieren und ich würde auch gerne den Protokolloverhead von NFS vermeiden, da an VM2 gern mal mit 10+ Clients "gesaugt" werden soll (via rsync). Wie würdet ihr hier vorgehen?
 
Proxmox auf SDD installiert, dazu gibts eine weitere SDD und 4 HDDs. Die HDDs sind ein zraid-pool. Auf dem proxmox sind mehrere VMs, unter anderem auch eine die Dinge aus dem Internet herunterlädt und eine weitere die diese Dinge als rsync server mehreren clients zur Verfüung stellen soll. Also VM1 schreibt und liest, VM2 stellt lesend zur Verfügung. Ich würde ungern die Daten duplizieren und ich würde auch gerne den Protokolloverhead von NFS vermeiden, da an VM2 gern mal mit 10+ Clients "gesaugt" werden soll (via rsync). Wie würdet ihr hier vorgehen?
Wenn du kein NFS Overhead haben willst, würde ich auf die Virtualisierung verzichten und Container nutzen. Da kannst du dann auch einfach einen shared folder via Bind Mount einbinden: https://pve.proxmox.com/wiki/Linux_Container
 
Leider muss das Viech das die Downloads macht eine VM sein, das liegt schon als qmu vor.
 
Ich würd für meinen Proxmox Server gerne pihole, navidrome und photoprism als LXC Container laufen lassen, damit Sie einfach einzurichten und leichtgewichtig sind sowie das Dateisystem mit dem Host einfach sharen können. Leider gibts die nicht fertig als LXC, aber ich hab etwas gefunden, was vielversprechend aussieht.

Kennt jemand von euch die Helper-Scripts von tteck (gibts auch auf github)? Falls ja, was ist davon zu halten? Für mich sieht das aus, als hätte sich da jemand echt Mühe gemacht und als würden die noch regelmäßig gepflegt... Neben den LXC Containern sind auch die Post-Install Scripts interessant, die Einstellungen vornehmen, Nag-Screens entfernen etc.


Und: Wenn ich Space zwischen VMs sharen will, dann ist ja EIN gängiger weg, ne VM mit TrueNAS core einzurichten, die viel Platz bekommt und darüber mit den anderen VMs über Netzwerk (z.B. NFS oder Samba) und VirtIO (wegen Performance) zu sharen, richtig? Oder würde man das auf dem Host einrichten um möglichst keinen Platz zu vergeuden?
In meinem Fall habe ich 2TB zur Verfügung (real 1862 GB)und würde der TrueNAS core VM gerne 1,75TB (1750GB) geben. Macht das Sinn? Und kann / sollte man die LXC Container dann auch auf ein Netzwerk-Share in der VM auslagern?
Sorry wenn das ne Anfängerfrage ist, aber die Möglichkeiten überwältigen mich ein bisschen ;)
 
Zuletzt bearbeitet:
Pihole: warum nicht das Original-Skript verwenden?

Truenas: warum nicht Scale?
 
Warum keine Docker VM aufsetzen? Dann hast alles kompakt in einer VM und kannst bei Bedarf einfacher portieren/verschieben.
 
Pihole: warum nicht das Original-Skript verwenden?

Truenas: warum nicht Scale?
Die Scripte passen die jeweilige Installation noch weiter an, das macht das original Script nicht. Ich hab mir das mal grob angeschaut und vieles davon ist sinnvoll bzw. hab ich bei mir auch gemacht. Ist durch aus interessant.
TrueNAS Scale ist noch sehr.... "bumpy" - würd ich auch nicht nehmen.
Warum keine Docker VM aufsetzen? Dann hast alles kompakt in einer VM und kannst bei Bedarf einfacher portieren/verschieben.
Container-VM statt "nativer" Container. Nene, Docker ist LXC auf Proxmox in fast allen Belangen unterlegen.
 
Doch doch, ich hab hier nach wie vor durchaus Trouble mit. Ich geb dem ganzen alle 1, 2 Monate wieder ne Chance (hab Core auf Proxmox laufen) und verschiedenste Dinge laufen immer wieder unrund - seien es nigghtly replication tasks, seien es komischen Treiberprobleme auf meiner Mellanox die unter Scale gern mal auf Gibabit zurückfällt, vor einiger Zeit hats mir mein zraid mal zerschossen, etc pp. Das ist nicht umsonst von den truenas Leuten als unfertig tituliert. Ich hoffe das ist bald anders, denn ich bin mit Debian deutlich firmer als mit BSD.
 
Würde mir gerne einen schlanken Mini-PC / Thinclient als reines 24/7 Zweitsystem für kleinere Services u.a. zur Ablösung von RPi‘s. anschaffen.

Mögliche Inhalte:
- debian VM mit Incinga, Graphite
- debian VM für Deconz/ Phoscon und Homebridge
- Diverse Container (iobroker slave, Vaultwarden, JDownloader, Statping, Wireguard)
- Ggfs. pfsense

Als Budget für die Grund-Plattform soll bei ca < 200€ liegen. Zusätzlich würde ich RAM, SSD ans Limit ausbauen.

Welche Plattform wären empfehlenswert?
Lenovo M710q oder M900, Fujitsu Futro S740 oder was komplett anderes?
 
Das sagt mir jetzt nichts.
Habe gehofft hier Tipps von erfahrenen Usern zu bekommen, nach dem Motto: „Kauf das Refurbished Nobrainer-Modell XY für deine Anforderungen in der Bucht“ stopf 32GB RAM rein. Fertig ist die Grundlage für die Proxmox Installation.
 
Würde mir gerne einen schlanken Mini-PC / Thinclient als reines 24/7 Zweitsystem für kleinere Services u.a. zur Ablösung von RPi‘s. anschaffen.

Mögliche Inhalte:
- debian VM mit Incinga, Graphite
- debian VM für Deconz/ Phoscon und Homebridge
- Diverse Container (iobroker slave, Vaultwarden, JDownloader, Statping, Wireguard)
- Ggfs. pfsense

Als Budget für die Grund-Plattform soll bei ca < 200€ liegen. Zusätzlich würde ich RAM, SSD ans Limit ausbauen.

Welche Plattform wären empfehlenswert?
Lenovo M710q oder M900, Fujitsu Futro S740 oder was komplett anderes?

Wie wärs mit sowas?

 

topton ali.jpg


Da bietet sich sowas an:

komplett passiv - Stromverbrauch Idle ca 9w, Vollast ca 25w
CPU Intel Celeron N5105 / 4c4t / 2,0 - 2,9 Ghz
max. 32 GB Ram (2x 16 GB S0 Dimm)
Storage 2x NVMe + 1x SATA + 1x microsdhc Slot
LAN 4x 2,5 Gbe
Video HDMI+DP
2x USB 2 + 2x USB 3

Gibt die in mehreren Versionen, die neue V4 Version mit 4 Port Intel 226 ist derzeit die einzige mit 2x NVMe Slot.
Die älteren mit Intel 225 oder 6 Ports haben nur 1 NVMe + 1x Sata.

Inkl. Zoll etc kosten die Dinger ca. 180-200 Euro. Lieferzeit war bei mir 4 Wochen.

Muss man leider selber importieren, in Deutschand habe ich nur die älteren Versionen gefunden,
oder zum 2-3-fachen Preis, oder nicht lieferbar.
 
Zuletzt bearbeitet:
Na ja, sowas wie iommu aktivieren ist halt plattformspezifisch und eine Kerneloption. Daher gibt es da auch keine Klickibunti Option für.

Alle Klickibunti Settings werden in /etc/pve/ gespeichert. Aber sowas wie die Kernel cmdline Parameter sollte man lieber nicht über die GUI bearbeiten, da im schlimmsten Fall dann das System einfach nicht mehr bootet. Daher verstehe ich auch die Entscheidung der Proxmox Entwickler dies nicht direkt über die GUI zugänglich zu machen, da man hier wissen sollte was man tut.

Ist IOMMU aber einmal aktiviert, dann ist der PCI-Passthrough selbst problemlos über die GUI möglich.

Das Thema Virtualisierung ist neu für mich - ev. verstehe ich es deshalb nicht so ganz!?

Proxmox ist ja ein "OS" welches für Virtualisierung gemacht wurde - warum ist dann "passthrough" nicht von Haus aus aktiv - das wird man ja öfter mal brauchen und nicht nur in Spezialfällen, oder?


LG
 
warum ist dann "passthrough" nicht von Haus aus aktiv - das wird man ja öfter mal brauchen und nicht nur in Spezialfällen, oder?
Weil es eine experimentelle Option laut Wiki ist und daher der Einsatz auf Produktivsystemen nicht empfehlenswert ist.
 
Weill PCIe passthrough nicht nur von der Hardware, sondern auch von der Bios-Konfiguration abhängt UND bestimmte Features damit nicht mehr funktionieren (Migration von VMs, bestimmte Containergeschichten etc). - es wird im allgemeinen davon ausgegangen das die Anwender von Virtualisierern sich auch damit auskennen. Dieses Auskennen führt dann auch dazu das man sich nicht ausversehen den Virtualiserer brickt - oder ihn zumindest wieder entbricken kann (been there, done that). Das ist aber kein Problem an sich - man liest einen Guide bzw. WiKi-Artikel, macht sich nch etwas schlau in Sachen Hardwarevirtualisierung mittels der Suchworte VT-d und IOMMU und ist "good to go" wie es so schön heißt. Und wenn das mal nicht reicht, fragt man seine "dummen" Fragen einfach hier - ebenfalls "been there, done that" ;)
 
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