Umstrukturierung: TrueNAS und die Apps

[gea]

Der Hardware-Support unter Linux ist besser. .

"Irgendeine" Hardware bringt man natürlich unter Mainstream Linux oder Windows am Besten zum Laufen.

Wer Unix (Free-BSD, OSX, Illumos, Solaris) will, weiß das und wählt Hardware gezielter nach der HCL aus.
Wobei es so ist - vor allem mit ZFS, dass deren üblichen Hardwareempfehlungen meist auch für Linux oder Windows Software Raid die beste Lösung ist.

 

[toscdesign]

Mal ein kleines Update von meiner Seite.
Bei der Umstellung bin ich leider 0,0mm weiter gekommen.

Das einzige was ich aktuell eingerichtet habe, ist ein Proxmox Backup Server welcher per NFS auf das NAS schreibt.
Das funktioniert super zuverlässig seit Dezember 2025 und das obwohl es über eine 1Gbit LAN Verbindung vom Proxmox Host zum TrueNAS Host läuft.

Bin immer noch am überlegen wie ich das ganze nun umsetze.
Ob ich 2 Maschinen behalte, oder auf eine umstelle, oder oder oder.
Bin erstmal froh, das mit NFS soweit stabil zum Luafen bekommen zu haben.

 

[toscdesign]

Ich habe mir mal weiter gedanken zu dem Thema gemacht und mal zwei Varianten durchgespielt.
Bin aber mit beiden Varianten nicht zu 100% zufrieden.

Variante 1:
- vom Datenspeicher inkl. Snapshots und Replication kaum bis keine Arbeit
- dafür viel NFS zu konfigurieren

Variante 2:
- alles wird im Pool gespeichert, hier kein NFS notwendig
- Snapshots und Replication müssen komplett von Hand gemacht werden

Bei beiden Varianten müsste ich die USV neu einbinden, bei Variante 2 wahrscheinlich mit mehr Aufwand.




Vor 3 Jahren (dachte es wäre länger her) hatte ich mir mal Scripte gebastelt, welche den Startvorgang unter Ubuntu mit einem btrfs Pool (verschlüsselt über luks) steuern sollten:

GitHub - toscdesign/NAS_scripts: a collection of scripts for a NAS

a collection of scripts for a NAS. Contribute to toscdesign/NAS_scripts development by creating an account on GitHub.

github.com

Davon kann ich zwar nichts mehr verwenden, aber es wäre zumindest für mich machbar einige Dinge selbst in die Hand zu nehmen.

Nicht beachtet wurde nun das NAS welches sich aktuell um die Offsite Backups kümmert. Dieses läuft auch unter TrueNAS Scale aber ohne Apps nur als Datenspeicher.

 

[toscdesign]

Also ich werde erst am mit Variante 1 ins Rennen gehen und die Dienste von Speicher entkoppeln.

Dann wird sich zeigen ob TrueNAS zu ersetzen sein wird, besonders mit dem Bezug auf diese neuen Bedingungen:

https://www.reddit.com/r/selfhosted/comments/1rpck7k/truenas_build_system_going_closed_source/

 

[pwnbert]

Spannende Wendungen, alles sehr mühsam. Am Ende dann vllt. doch Proxmox mit Freigaben direkt? Mir wäre die Filer-VM immer noch lieber, aus Gründen, mal sehn...

Aber gut, erstmal sehen, wo sich die Sache hin bewegt.

 

[toscdesign]

Das ist der Vorteil von Variante 1, ich kann alle Dienste von Filer entkoppeln und erst als den Filer unverändert in einer VM weiter betreiben.

Wird es notwendig, dann kann ich den ZFS Pool exportieren, in Ubuntu, Debian, Proxmox oder sonst wo importieren und alle Daten bleiben erhalten.

 

[Spliffsta]

Ist doch alles gut

Scale-build git repo going closed source

Here is a comment from Reddit. Seems like it is really only about the build toolchain. It’s reasonable and clears the confusion I think. kmoore134 wrote: Bottom line is, the open source bits of TrueNAS will remain open source. (They are GPLv3 after all). The build system is another matter...

forums.truenas.com

Bottom line is, the open source bits of TrueNAS will remain open source. (They are GPLv3 after all). The build system is another matter. It’s currently changing fairly radically internally now around for a variety of reasons, some of which are related our signing infrastructure for secure boot, etc. Meaning we’d be stuck maintaining two separate builders potentially to assemble an ISO file, one for community builds, one for the official builds. That isn’t super tenable for us in the long term.

That said, the repo is still there. Folks can fork / maintain it. All the open source bits can be built if the community so desires this functionality. But I’d wager 99% of the folks commenting on this thread have never done a build from source before, nor would ever want to? Its a lot of work to do and maintain. Especially since the biggest consumers tend to be overseas forks which contribute nothing back to the overall development effort to create TrueNAS, thats a lot of effort for us to shoulder the burden on for no real gain.

 

[toscdesign]

Bottom line is, the open source bits of TrueNAS will remain open source.

Und wer bestätigt mir, das teile des Codes nicht zukünftig in closed source neu geschrieben werden, damit das langsam inkompatibel wird?

Edit:
1. Ich muss sowieso Änderungen vornehmen, siehe Thread Anfang. Die Apps kann ich nicht mehr migrieren.
2. Ich möchte auf Grund der aktuellen Infos einfach flexibel werden um notfalls switchen zu können.

 

[pwnbert]

Und wer bestätigt mir, das teile des Codes nicht zukünftig in closed source neu geschrieben werden, damit das langsam inkompatibel wird?

This.

Btw., wie ist das eigentlich zu verstehen?
Hat die Enterprise-Version irgend nen brauchbaren Hypervisor?

 

[toscdesign]

Nutzt TrueNAS Scale sowieso nicht KVM?
Dann lieber direkt Proxmox, die können das besser.

 

[pwnbert]

Nutzt TrueNAS Scale sowieso nicht KVM?

Jein, die Art und Weise wie man es konfigurieren kann (bzw. eher wie man es nicht kann) ist imho der Knackpunkt.

 

[toscdesign]

Vorbereitungen
Zuerst musste ich die Config von TrueNAS sichern, damit ich diese dann in die VM laden kann.
Dann logischweise zur Sicherheit die beiden Fesplatten abgeklemmt, damit ich die nicht ausversehen überschreibe.

Proxmox Installation
Hier musste ich erstmal die TrueNAS "Signature" von der NVMe SSD löschen, da sich sonst Proxmox geweigert hat das TrueNAS System zu überschreiben.
Ging ganz einfach mit folgendem Befehl unter einem Livelinux:

wipefs -a /dev/nvme0n1

Dann habe ich nun ganz klassich ohne viel Schnick-Schnack das Proxmox mit der Standardeinstellung und ext4 auf die 500GB NVMe SSD installiert.

Als Hostname habe ich mich für was besonderes entschieden, normalerweise mache ich das nicht, hier habe ich aber mal die Ki bemüht.
Finde das passt ganz gut zum Kontext:

„Ciel“ ist das französische Wort für
Himmel und stammt vom lateinischen caelum ab. Es steht symbolisch für Weite, Freiheit, Transzendenz und den paradiesischen Bereich.

Vorbereitungen
Erstmal auf der frischen Installation, die IOMMU Fahigkeiten geprüft.
Im BIOS war alles aktiviert, daher lief das alles direkt ohne Probleme durch.
Anleitung: https://pve.proxmox.com/wiki/PCI_Passthrough
Dann ganz klassich für Proxmox die Enterprise Repositorys deaktiviert und das Non-Subscription Repository aktiviert.
Und erstmal die neusten Updates installiert.


Nachbereitungen
Naturlich den Rechner noch im falschen Netz gehabt und daher ne falsche IP vergeben.
Proxmox selbst sollte natürlich im Management Netz liegen und nur die VMs in den entsprechenden anderen Netzen.
Das also alles umgestellt und nix geht mehr.
Nach einer Stunde ist mir dann aufgefallen, das der Switchport noch auf dem falschen PVID stand.
Warum wird das nicht passend zum "untagged" Member beim Ändern der VLAN Konfiguration mit angepasst?
Wo ist der Sinn, den Untagged Member z.B. auf VLAN 8 aber PVID 5 zu setzen, das macht null Sinn.


TrueNAS VM
Die installiert gerade. Alle Infos hierzu füge ich nachträglich in diesen Post ein.
Möchte heute auch mal Feierabend machen 😅

 

[BobbyD]

das macht null Sinn

Es macht dann Sinn, wenn man Ports (Geräte) voneinander trennen will, die aber alle im selben Layer3-Netz sind. Das nennt sich dann Portbasierte VLANs.

Warum Proxmox nicht auf ZFS installiert?

Beitrag automatisch zusammengeführt: 10.03.2026

Das also alles umgestellt und nix geht mehr.

Jo, das nervt mich auch, wenn alles über einen klassischen Webserver gemanagt wird, die sind da verdammt unflexibel.

 

[toscdesign]

Es macht dann Sinn, wenn man Ports (Geräte) voneinander trennen will, die aber alle im selben Layer3-Netz sind. Das nennt sich dann Portbasierte VLANs.

Verstehe ich nicht, wenn ich ein Gerät in VLAN 5 haben will dann komplett und nicht zur Hälfte.

Warum Proxmox nicht auf ZFS installiert?

Warum sollte ich das tun, bei einer einzelnen SSD? Da bringt ZFS keinen Vorteil. Die VMs werden sowieso regelmäßig per PBS gesichert.

Jo, das nervt mich auch, wenn alles über einen klassischen Webserver gemanagt wird, die sind da verdammt unflexibel.

Meinst du jetzt den Switch oder Proxmox?
Ich könnte Proxmox nicht mehr erreichen, der Switch ging immer.

 

[BobbyD]

ZFS ist aber auch kein Nachteil. Sowohl PVE als auch PBS laufen bei mir auf ZFS, ohne RAID. Denke, das ist optimal, aber natürlich kein Muss.

 

[pwnbert]

Bin mir bei der Frage momentan auch nicht ganz sicher...
Die Schreiblast dürfte nur mit Cluster-Kram ein Thema sein, wenn ich das richtig durch hab.

Meine ZFS Erfahrungen auf TrueNAS sind äußerst positiv, wie das alles "ohne Eingriffe" funktioniert hat, als bei meinem SVDEV Mirror die SSDs "weggefallen" sind (also der Adapter das Signal verloren hat).

 

[toscdesign]

Bin mir bei der Frage momentan auch nicht ganz sicher...
Die Schreiblast dürfte nur mit Cluster-Kram ein Thema sein, wenn ich das richtig durch hab.

Cluster? Sowas kann ich mir nicht leisten 😅

Meine ZFS Erfahrungen auf TrueNAS sind äußerst positiv,

Meine auch, aber für einen VM Host als Dateisystem brauche ich es für meinen Einsatzzweck nicht.

 

[Haldi]

„Ciel“ ist das französische Wort für
Himmel und stammt vom lateinischen caelum ab.

Ahwas...
Ciel ist nen Charakter aus Melty Blood act Cadenza.

 

[toscdesign]

Was?

 

[BobbyD]

wenn ich das richtig durch hab

Wenn man in ZFS Sync-Writes abstellt, dann ist die wohl nicht mehr nennenswert erhöht. So mache ich das jedenfalls.

 

[toscdesign]

Ach ja, TrueNAS mag mich besonders.
Sind wohl die Server für die alten Apps abgestellt worden 😑

Der rödelt schon seit gestern Abend:

 

[pwnbert]

Meine auch, aber für einen VM Host als Dateisystem brauche ich es für meinen Einsatzzweck nicht.

Jein, Mirror hätt ich schon gern, und nach diesen Erfahrungen gehe ich irgendwie davon aus, dass ein ZFS-Mirror deutlich robuster und einfacher sein dürfte als ein LVM-Raid-1, ob das stimmt, ist natürlich die Frage.

Zudem ist für mich die Frage, inwiefern der ARC-Cache hier von Vorteil ist.
So groß ist das ganze Debian-Proxmox OS ja nicht, eigentlich sollte alles irgendwie Relevante davon dauerhaft im ARC seinen Platz haben (selbst wenn der ARC nur ein paar GB sind).
Oder ist Linux ohnehin so aufgebaut, dass alles Relevante ohnehin im RAM liegt? Keine Ahnung.

LZ4 ist vllt. auch nicht so schlecht, gerade beim OS und VMs (und Backups davon) sollte man damit doch eine merkbare Compression hinbekommen...

Wenn man in ZFS Sync-Writes abstellt, dann ist die wohl nicht mehr nennenswert erhöht. So mache ich das jedenfalls.

Naja, ist immer noch ein CoW FS mit all einen Späßen.
Aber stimmt schon. Das und ggf. noch manuell reduziertes Logging (ich kann mit den Logs eh nichts anfangen, wenn mich ein Problem längerfristig quälen würde, könnte man es ja aktivieren zur Fehlersuche)...

Eher frage ich mich, wie das mit der Schreiblast auf VMs aussieht.
Wenn ich richtig verstehe, ist so ein "Speicherplatz" für eine VM dann einfach ein ZFS Dataset am Pool?
Beim LVM hingegen könnte man für "unkritische" VMs einfach ein Stück vom LVM-Thin durchreichen und dort dann einfach ext4 verwenden?

 

[toscdesign]

Jein, Mirror hätt ich schon gern,

Kann ich nicht nutzen, hab keinen zweiten NVMe Slot.
Daher tägliches Backup per PBS auf die HDDs mit ZFS (die als Mirror laufen).

Und von da täglich ein Offsite Backup, fall die Bude leergeräumt wird oder so.

 

[BobbyD]

und ext4 auf die 500GB NVMe SSD installiert.

D.h. die 500 GB NVMe beherbergt nur Proxmox? Das wäre für mich Verschwendung, ich hätte dort alle Gäste untergebracht. Aber gut, vermutlich hast Du was völlig anderes im Kopf und jegliche Diskussion dazu ist nicht zielführend.

Wenn ich richtig verstehe, ist so ein "Speicherplatz" für eine VM dann einfach ein ZFS Dataset am Pool?

Bei VMs sind das wohl "ZVOL Datasets" (lt. Proxmox Docs), bei LXCs, wie ich sie einsetze, sind es einfach Datasets.

Punkt ist, ich sehe keine Nachteile mit ZFS, wenn man ein paar Sachen beachtet. Man könnte wohl inzwischen sogar nachträglich noch ein RAID einrichten, wenn man das wollte. Ich will das nicht.

 

[toscdesign]

LZ4 ist vllt. auch nicht so schlecht, gerade beim OS und VMs (und Backups davon) sollte man damit doch eine merkbare Compression hinbekommen...

Puh, das ist nur ein Odroid H3 mit dem Intel N5105 😅

D.h. die 500 GB NVMe beherbergt nur Proxmox? Das wäre für mich Verschwendung, ich hätte dort alle Gäste untergebracht. Aber gut, vermutlich hast Du was völlig anderes im Kopf und jegliche Diskussion dazu ist nicht zielführend.

Sorry, da habe ich mich falsch ausgedrückt.
Da läuft Proxmox selbst + alle VMs und LXC dann drauf auf der SSD.

Nur die Daten selbst (nicht die Datenbanken falls es welche gibt) werden per NFS an TrueNAS weitergereicht.

 

[BobbyD]

Nur die Daten selbst (nicht die Datenbanken falls es welche gibt) werden per NFS an TrueNAS weitergereicht.

Das klingt jetzt eher so, dass jeglicher Gäste-Storage auf TN läuft, hältst Du das für eine gute Idee. Warum will man das in 2026 so machen.

 

[toscdesign]

Verstehe nicht worauf du hinaus willst?

 

[BobbyD]

Verstehe nicht worauf du hinaus willst?

Ich will hier nur Denkanstöße geben, ich weiß weder, was das Beste für dich ist, noch bin ich ein Profi, was das Thema betrifft.

Für mich gehören Gäste immer auf SSDs, nicht auf HDDs.
Sämtlichen Storage "remote" zu halten (egal ob nun HDDs oder SSDs), statt ihn direkt auf dem Virtualisierer zur Verfügung zu stellen, erscheint mir unnötig komplex und weniger performant.
Ausnahme davon sind immer Gäste, die massiven Storage benötigen. Für diese würde ich mir dann ggf. was anderes ausdenken, aber das Gros kann einfach direkt auf dem Virtualisierer vorgehalten werden. Zumindest zu Hause, wo ich Performance mit beschränktem Budget und geringen Betriebskosten unter einen Hut bringen will.

 

[pwnbert]

LZ4 hat bei mir keine sichtbare Last verursacht in meinen bisherigen Tests. zstd schon deutlich, je nach dem wie hoch die compression war mehr oder weniger...

[Sammelthread] - ZFS Stammtisch

Hatte jetzt auch schon 2mal den Fehler NOTICE: cpu1: started, but not running in the kernel yet WARNING: cpu1: timed out NOTICE: System detected 8 cpus, but only 7 cpu(s) were enabled during boot. NOTICE: Use "boot-ncpus" parameter to enable more CPU(s). See eeprom(8). Kommt aber nicht immer...

www.hardwareluxx.de

Man findet ja dies und das wenn man so googelt... auf jeden Fall ist LZ4 großartig und richtig "leicht"... lohnt schon zu verwenden imho. Wsl. selbst am Celeron.

Nachtrag:
Ich versteh ich nicht so ganz, warum bei btrfs auf zstd gesetzt wird, LZ4 ist einfach so schnell und leicht, so viel schneller selbst als zstd-1...
Das mit der Kompressions-Rate ist ja so eine Sache, im Real-Life ist das so ne Sache... und ob die Kompresionsrate jetzt z.B. 1,42 oder 1,60 ist (mein Beispiel)... ja so what.
Dafür, dass LZ4 "nichts" kostet, kann man das imho mitnehmen. Hat ja zudem auch early abort, bricht also die Kompression ab wenn nicht auf 7/8 verkleinert werden kann und speichert den Rest unkomprimiert (zstd kann das imho nicht), Medien werden also einfach so gespeichert, benötigen dann auch keine Leistung beim Schreiben/Lesen.

Der Preis für etwas höhere Kompressionsraten bei zstd und speziell den höheren zstds ist imho enorm, das macht dann richtig (!) CPU-Last (also vllt. das 20 oder 200 fache von LZ4) und wird beim Schreiben echt langsam. Vielleicht lohnt das fürs Backup von Datenbanken oder so - keine Ahnung.

Zumindest ist mein tl,dr: aus der Sache, dass LZ4 daheim super ist.

 

[toscdesign]

Für mich gehören Gäste immer auf SSDs, nicht auf HDDs.

Sind doch auf der SSD

Sämtlichen Storage "remote" zu halten (egal ob nun HDDs oder SSDs), statt ihn direkt auf dem Virtualisierer zur Verfügung zu stellen, erscheint mir unnötig komplex und weniger performant.

Eins nach dem andern, schau die mal meine Ausgangssituation an. Ich muss während dem laufenden Betrieb "umziehen" und das versuche ich Schritt für Schritt. Dabei nutze ich die Chance alles zu modularisieren, damit ich ggf. in Zukunft eine Komponente einfach austauschen kann.

Mir hat das Thema TrueNAS gezeigt: "verlasse dich auf niemanden, packe nicht alles in ein System". Hätte ich damals die Apps nicht in TrueNAS sondern in eine VM mit Docker gesteckt, wäre der Updatepfad von TrueNAS total irrelevant gewesen. So wie jetzt habe ich eben die berühmte Arschkarte.


Wahrscheinlich bleibe ich auch nicht bei TrueNAS als Filer, wenn das so weiter geht. Was da als Ersatz kommt weiß ich noch nicht. Erstmal muss das System wieder laufen damit ich weiterarbeiten kann.

Folgendes funktioniert schon:
- SMB Shares
- NFS Shared
- Replication offsite
-> ich komme an alle Daten

Folgendes läuft leider überhaupt nicht (danke TrueASS):
- Nextcloud
- Immich
- gitea

Die Daten liegen noch auf den Datasets, komme also dran. Die Datenbanken liegen auch dort, muss mir nur überlegen wie ich diese (da alte App Versionen) in die neuen App Installationen überführen kann.
Bis auf gitea, da komme ich nicht mehr ran. Da das Datenbankpasswort von TrueNAS generiert wurde und gehasht ist.