TrueNAS Scale - div. Themen

[pwnbert]

Liebes Forum, ich beginne her einmal einen TrueNAS Scale Thread, nachdem wir noch keinen haben.
Ich fühle mich zwar nicht wirklich dazu geeignet einen "Sammelthread" zu starten, wie es hier einige gibt, aber schauen wir mal, wo das hinführt.


Die Grundfunktionen vom TrueNAS Scale habe ich mehr oder weniger im Griff, das ist nichts, vor dem man sich großartig fürchten müsste.

Momentan sind meine aktuellen Probleme/Fragen im Bereich der Virtualisierung (TNS als Host).
Vorab:
Mir ist bewusst, dass das keine ideale Konstellation ist, und TNS eben in erster Linie als NAS-OS geschaffen wurde, und ab einem gewissen Punkt ein Proxmox mit einem virtuellen TNS vielleicht die bessere Lösung wäre.
Die Sache ist entstanden, wie sie entstanden ist, da für mich die NAS Funktion schon im Vordergrund steht und ich mit Proxmox keine Erfahrung hatte, die Sache auch so gewachsen ist, da ich erst im Lauf der Zeit auf den "Geschmack" der Virtualisierung gekommen ist.
Auch die Idee den Filer und den VM-Host zu einem gewissen Zeitpunkt in 2 Systeme zu trennen ist sicher nicht falsch, aber irgendwo ist das vieleicht doch etwas mit Kanonen auf Spatzen, Hardware und Strom sind in der Größenordnung zwar leistbar, aber auch nicht gratis.
Insofern würde ich gern schauen, wie weit man mit TNS kommt.

Ich hab ein paar VMs (mit GUI), ich bin auf den Geschmack gekommen, gewisse Dinge einfach in einer VM am Server zu machen. Das ist nämlich unabhängig vom Zustand meines Desktop-PCs (ob der nun läuft oder nicht, in welchem OS man gerade ist...). Dafür hab ich schon etwas dies und das probiert, mit mehr oder weniger gutem Erfolg.



=> Mein System ist ein Ryzen Pro 5750G mit 128gb ECC (DDR4 3200 cl22) auf einem Asrock B550 Riptide PG (also ohne IPMI, gute PCIe Konfiguration). Ein MC12 hätte ich noch liegen, hatte damit aber was anderes vor.
Momentan bin ich bei EndeavourOS mit KDE (X11) im Guest, verbunden über Spice (virt-viewer am Win10 Desktop).


eOS mit KDE (X11) läuft verhältnismäßig gut, ich kämpfe da sporadisch mit ~10 sek. Freezes, wobei z.B. ein Firefox-Download im Hintergrund weiterläuft ohne abzubrechen, könnte also auch nur das spice sein? Der Host bleibt unbehelligt von der ganzen Sache, der ist stabil, es beeinflusst auch ein Freeze/Crash in einer VM keine andere VM. Ganz selten ist es auch ein Crash, also ein Freeze ohne Erwachen (meist beim Surfen im Firefox). Am häufigsten treten diese Freezes bei Benutzung des Dophin Dateiexplorers auf.
eOS mit XFCE mag gar nicht, offenbar ein Grafiktreiberproblem.

Ich vermute, dass das Problem in der Richtung "Grafikverarbeitung" zu suchen ist, tu mir da aber etwas schwer, da fehlt mir viel Erfahrung.

Inwiefern der Cezanne SR-IOV unterstützt? Wahrscheinlich nicht, aber schwer, da überhaupt was zu finden, so ganz schlau werd ich nicht aus der Sache. ( https://open-iov.org/index.php/GPU_Support https://wiki.archlinux.org/title/AMDGPU_PRO )

Die ganze IOMMU Gruppe durchreichen an die eOS XFCE VM hab ich dann zwar geschafft, allerdings ist die Maschine dann sehr unwillig in die Session gestartet, stecken geblieben und abgestürzt.

Wo wir zum nächsten Spaß kommen, nämlich den "AMD Reset Bug", von dem ich natürlich betroffen bin.
Inwiefern ich einen Workaround dafür ins TNS bekomme, bzw. inwiefern das relevant ist... nunja.


Ihr seht also, ich hab viel Spaß und stoße hier regelmäßig an meine Grenzen, erinnert mich ein bissl an Dark Souls ...
... ich bin für jeden sinnvollen Hinweis, wie man was besser machen könnte, dankbar.
LG

 

[Supaman]

Ich kann die Grundsätzliche Idee nachvollziehen, das man einen Filer gerne für mehr bzw besser benutzen möchte, wenn er denn schonmal da ist. Nested Virtualisation ist eine Sache, die man teilweise oder partiell nutzen kann, aber eben auch problembehaftet.

Da würde ich das Setup eher umkehren: Proxmox als Virtuasierer, und dann TrueNas als VM laufen lassen. Dazu kann man die Platten aus PVE 1:1 am die TN durch reichen, oder schliesst diese über einen separaten Controller an, und reicht dann den ganzen Controller an die VM durch.

Oder man nimmt ein separates System dazu, eine Intel n100 Box zieht <10w und ist den für den üblichen Kleinkram paar Docker Contrainer etc völlig ausreichend.

https://www.amazon.de/dp/B0CG18KSC4?psr=EY17

 

[pwnbert]

Ja, dass diese "Lösung" der Probleme (bzw. der Austausch gegen andere evtl. besser lösbare ) in Betracht zu ziehen sein könnte, hab ich mir schon vorstellen können.
Ich schließ nicht aus, dass ich meinen Filer mal virtuell betreibe, momentan bin ich davon aber noch ein gutes Stück entfernt.
Ich hab im Prinzip auch kein Problem damit etwas Geld für Hardware auszugeben, wenns nicht hart sinnlos ist.


Es funktioniert grundsätzlich ja nicht so schlecht... wahrscheinlich erkenn ich irgendwas nicht, was halb so wild ist.

root@...]# lshw -c video
  *-display                
       description: VGA compatible controller
       product: QXL paravirtual graphic card
       vendor: Red Hat, Inc.
       physical id: 2
       bus info: pci@0000:00:02.0
       logical name: /dev/fb0
       version: 05
       width: 32 bits
       clock: 33MHz
       capabilities: vga_controller bus_master rom fb
       configuration: depth=32 driver=qxl latency=0 resolution=1024,768
       resources: irq:10 memory:c4000000-c7ffffff memory:c0000000-c3ffffff memory:c8060000-c8061fff ioport:c0e

Was ich gefunden hab durch meinen Fehler mit XFCE war der Hinweis, dass es wohl an QXL liegen könnte und virgl möglicherweise besser sein.

Soweit okay, klingt für mich erstmal nach einem Weg, den man austesten könnte - ich find bloß keinen Weg, wie ich das anstellen könnte.

Hab jetzt mal glxgears laufen lassen. Anfangs sehr smooth, dann ein 10s freeze, dann wieder smooth, dann schneller ein feeze, dann hab ichs geschlossen.
Hab dann nochmal gestartet und nochmals das gleiche Spiel, Abstände zwischen Freezes wurden kürzer, schließlich Freeze in den Permafrost ohne Erwachen. Erhöhte CPU-Last am Host nicht feststellbar.
... als würde irgend ein buffer volllaufen?

Wäre mehr als dankbar, wenn jemand dazu was weiss.

edit: In den Logs, die ich auf TNS runterladen kann, hab ich nix drin. Der letzte Timestamp ist vom Startup. Der Perma-Freeze war mit glxgears reproduzierbar, ich lass das jetzt mal länger so "laufen", da die Maschine wohl aus Host-Sicht nicht gecrashed ist, sondern halt endlos langsam "lebt".

 

[pwnbert]

Ich bin jetzt mal soweit, dass ich herausgefunden habe, dass das wohl am aktuellen eOS Update liegt.
Ich hab es jetzt mal mit einem Kubuntu probiert, das out of the Box anständig läuft, wobei ich es noch nicht hinreichend getetet hab.

Ich werde erzählen.

Wenn jemand noch sinnvolle Tips zu dem Thema hat, immer gern.


... ich würde ja gern das Display irgendwie konfigurieren in der Host Verwaltung, offenbar geht das aber bei TNS nicht (wirklich). Was ich so raus lese, sind nur 16mb vga-ram drin, wobei ich nicht weiss, ob das mit qlx überhaupt von Bedeutung ist. Auch wenn jemand dazu was sagen kann, immer gern.
Mit Virtualisierung hatte ich weder in Ausbildung (gabs zu der Zeit nicht so wirklich, bzw. war ich auch nicht so weit fortgeschritten) noch Job (mach ja kein IT) je zu tun... also wenn jemand ein ein oder anderen Hint droppen möchte, gern!

 

[Supaman]

also wenn jemand ein ein oder anderen Hint droppen möchte, gern!

#1
Wenn Du funktionierende Virtualisierung betreiben möchtest, dann verwende einen richtigen Virtualisierer wie z.B. Hyper-V oder Proxmox und keinen Gemischtwarenladen wo an irgendein Media Produkt ein bissl Virtualisierung zur Abrundung der Featureliste drangebastelt wurde.

#2
Wie schon erwähnt, ist es durchaus sinnvoll, Use Cases zu trennen und nicht alles auf einen Host drauf zu packen. Vieles von dem, was man sich modular per Virtualisierung zusammen steckt, braucht nicht viel Ressourcen und muss einfach nur "da" sein. Ist also durchaus sinnvoll, sich ein 10w System hinzustellen, da die üblichen verdächtigen drauf laufen zu lasen. Früher hat man viel mit der RPIs gemacht, heute nimmt man Intel n100 oder einen ThinCLient dafür.

 

[pwnbert]

Ich weiss, ist eine mittelfristige Sache, die ich angehen werde.

Ich hab derweil weiter gemacht und wieder bissl was gelernt.
Das Problem liegt offenbar an EndeavourOS und X11, gab 2022 schon was recht ähnliches. https://forum.endeavouros.com/t/spice-performance-horrible/22563
Irgendwas am eOS dürfte broken sein, mit dem Kubuntu läuft das nämlich gut (mit X11).

Ich hab TNS jetzt auch auf Dragonfish geupgradet, spannenderweise hab ich mein Freeze-Problem (offenbar) nicht mehr... ich meine, es müsste damit zu tun haben...
Eigentlich eine ganz angenehme Erfahrung, die Paarung (Kubuntu X11 am TNS Dragonfish Host mit Win virt-viewer Client) läuft eigentlich überraschend brauchbar.

Jetzt mal schlafen.

 

[ebniv]

Kann mir jemand das Konzept mit den Update Trains erklären? So richtig schlau werde ich daraus nicht, es gibt nicht mal eine Übersichtsliste im Netz wo die Trains und Versionen aufgelistet sind.
Aktuell bin ich auf Bluefin mi TrueNAS Scale 23.10.2. Der Traun wird als EOL angezeigt. Daher vermute ich mal, dass es langsam Zeit wird für einen wechsel.
Kann ich einfach so auf Cobia oder Dragonfish wechseln und damit Updaten? Welches ist besser, und wenn Dragonfish, soll ich den Zwischenschritt über Cobia gehen?
Treten dort öfter mal Probleme auf oder geht das genauso gut wie die normalen Updates, welche ich ca. die letzten zwei Jahre unter Bluefin gemacht habe.

Edit:

you should not jump fom 22.12 to the latest version but rather do updates to latest bluefin, then to latest cobia then to lates dragonfish.

Differenc Bluefin, Cobia and Dragonfish

I want to update my Truenas scales. I currently have 22.12.3.3, in this version the charts no longer work. That’s why I want to update. What do I need to bear in mind?

forums.truenas.com

 

[pwnbert]

Ich meine das sind die Hauptversionen, B... C... D... alphabetisch.. ne Zeit lang ist dann eben A legacy, B stable und C beta und mit der Zeit springt das dann, dass B legacy wird, C stable und D beta.. so auf die Art.

Wenn ich das richtig verstanden habe.

 

[Haldi]

Kann mir jemand das Konzept mit den Update Trains erklären?

Vermutlich kann das schon jemand...
Aber das ändert sich in den nächsten 6-9 Monaten doch sowieso wieder. Wie alles bei Truenas.

Aktueller build ist Dragonfish 24.04.

Wichtige Infos... Ab 24.10 wollen sie ihre "apps" von Kubernetes weg auf Dicker zügeln...
Es "soll" alles ohne Probleme laufen....

 

[Rarity]

Kann mir jemand das Konzept mit den Update Trains

Train = Software-Versionstand

Je ausgiebiger eine Software getestet bzw. je länger diese im Einsatz ist, desto höher ist die Wahrscheinlichkeit das Programmierfehler ("Bugs") gefunden und behoben werden können, durch diesen kontinuierlichen Verbesserungsprozess sinkt typischerweise die Anzahl der Fehler in der Software und kann im Idealfall (ich sagte *im Idealfall*) sogar den Wert Null erreichen *hüstel*.

Abhängig von den Benutzer-Anforderungen an den Reifegrad der Software, empfiehlt Dir https://www.truenas.com/software-status/ eine bestimmte Version ("Train") der TrueNAS-Software.

Ich z.B. bevorzuge, im Jargon der TrueNAS-Webseite, den Software-Entwicklungsgrad "Conservative" (oder noch besser ausgetestet), was derzeit die empfohlene Version 24.04.2 (also Codename "Dragonfish") wäre.
24.04. gibt Jahr und Monat des Software-Release am (hier: Jahr 2024, 4.tes Monat), die letzte Ziffer gibt die Anzahl der danach erfolgten Bugfix-Zyklen an (hier: 2).

Eine nächste große Software-Version (Weiterentwicklung von TrueNAS) besitzt dann ein neueres Erscheinungsdatum bei Jahr/Monat, Bugfix-Zyklus Zähler beginnt initial wieder bei ".0" , und bekommt im Vergleich zur Vorversion, einen Codenamen welcher mit dem nächsthöheren Buchstaben des Alphabets beginnt.

Im Prinzip hat es @pwnbert, weiter oben gepostet, schon gesagt.