[Sammelthread] Proxmox Stammtisch

Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Dass da wer den Filer im durchgereichten HBA Storage hochzieht, höre ich zum ersten mal. Macht das wer?
Hab ich auch noch nicht gehört. Mit Hyper-V würde das z.B. gar nicht gehen. Würde daher Abstand davon nehmen.
 
Würde meinen, wenn der HBA im IT Modus ist, kann gar nicht davon gebootet werden? Zumindest in meinem Host tauchen die Platten erst auf, nachdem der gestartet wurde. Die seh ich nicht im BIOS, oder (in meinem Fall unter ESXi) im Hostclient. Die Platten sehe ich erst im gestartetem Filer, und von dem HBA BIOS sehe ich gar nie was. Kommt aber auch auf den HBA und die Firmware an. Die ganzen ZFS Freaks mögen ja die IT Firmware.
 
So, ich hab hier die Option, von der vorher gesprochen wurde, hilft aber nicht weiter.
1728504630321.png

Würde meinen, wenn der HBA im IT Modus ist, kann gar nicht davon gebootet werden?
Okay, ich glaub euch schon, dass das unüblich ist.
Aber es geht ja wunderbar - also why not? Soll ich euch ne Bildergeschichte machen, damit ihr es glaubt?

Es ist so, mit SeaBios rebootet er irgendwann nachm HBA initialisieren. Wenn ich da ESC drücke für die Boot-Optionen (mehr gibt das SeaBios mit dem Proxmox Logo ja nicht her offenbar), wähle ich dort 1. legacy (wie am ersten Screenshot), dann bootet er mir sauber.
 
Frag mal @gea, die ist da super Profi. Die kann das sicher besser erläutern. Halte mich da auch nur an Vorgaben, die von den ganzen Nerds gemacht werden. Eine davon ist, dass für ZFS der HBA im IT Mode sein sollte. Damit er nirgends rein funkt hardwaremässig. Im IT Mode ist er halt dumm, und das OS regelt alles. IR Mode ist eher für Hardware RAID und sowas gedacht.
 
Warum soll das "richtig" sein? Warum soll ich das OS aufn virtuelles Drive machen, geht doch wunderbar auf ein durchgereichtes.
Muss nur irgendwie automatisch gehen.

Sorry, die Antwort ist sinnlos. Das is so wie "welche Grafikkarte soll ich für den Gaming PC kaufen" und jemand sagt "kauf einfach ne PS5". Yeah right.

Sorry, ist einfach keine Hilfe.
Richtig im Sinne von "best practice". War vielleicht falsch ausgedrückt. Beim virtuellen OS kannst halt easy Backups machen oder vorm Update noch nen Snapshot.
Will dir in dein Gebastel nicht reinreden, finde es interessant.

Die anderen Möglichkeiten wollte ich nur erwähnt haben. Für dich keine Hilfe, klar, weil du Truenas nutzen willst. Aber für andere vielleicht eine Hilfe.
 
Versteh schon. Nachdem es aber offenbar (irgendwie) funktioniert, frag ich mich, wie wohl richtig.
Ich könnte es natürlich nochmal am HBA neu installieren... wer weiss?

Ehrlich gesagt bin ich selbst am überlegen, ob ich das OS einfach virtuell machen soll... damit habt ihr schon recht. Geht am Ende ja nur um die Konfiguration.
Ich fände es trotzdem irgendwie elegant.
Hat wohl beides seine Vor und Nachteile.


Begonnen hat mein Plan damit, dass ich mit möglichst wenig Aufwand ein TrueNAS von baremetal auf Proxmox übersiedeln wollte, wenn der Rückweg ebenso problemlos und kinderleicht ist, wäre das natürlioch kein Schaden, dachte ich.
 
Wenn Du virtuell installierst, hast Du sowohl die virtuelle Boot Platte als auch den HBA Storage an TrueNAS. Genauso wie wenn Du es vom HBA aus bootest.

Wenn Du den bestehenden Storage importieren willst a) backup Config einspielen, oder b) Pools rasch importieren. Bei b) werden praktischerweise auch die ganzen Berechtigungen übernommen; war selbst ganz erstaunt, dass das geht. Zumindest unter napp-it.

Es war/ist/handelt sich um einen ZFS Storage, oder? Wenn ja, würde ich mich erst mal darum kümmern, ob der HBA im IT Mode läuft...

Und Rückweg gibt es nicht. Also schon. Aber nicht auf dem highway to rabbit hole. Keine Ahnung, hatte seit 15 Jahren kein Blech mehr am laufen.
 
Zuletzt bearbeitet:
Als Anmerkung
Bei ESXi ist AiO die einzige Möglichkeit, lokales ZFS Storage im ESXi Server zu haben. Das ist da alternativlos.

Bei Proxmox hat man ja bereits ein Debian mit aktuellem ZFS serienmäßig. Da bringt eine Storage VM egal ob mit einem weiteren Debian (TN) oder Solaris/OmniOS ZFS mäßig überhaupt keinen Vorteil sondern nur den Komfort einer Weboberfläche für ZFS Management, kostet nur dafür aber ordentlich Speicher und CPU. Bei Solaris/OmniOS hätte man immerhin noch den kernelbasierten SMB Server statt SAMBA und etwas weniger Resourcenbedarf.

Bei Proxmox lautet die Alternative, SAMBA einfach nachzuinstallieren ohne Storage VM. Für ZFS Management gibt es ja neben meinem napp-it eine ganze Reihe von ZFS Web-GUIs für Linux.

Bei ESXi ist NFS das Mittel der Wahl. Bei Proxmox genügt eigentlich SMB für Datentransfers, NFS brauchts nicht. Damit umgeht man das Problem dass NFS3 keine Authentifizierung oder Authorisierung kann (nur Restriktionen auf ip) und NFS4 gerne imständlich wird. Bei SMB sind ACL Rechtevergaben kein Problem (ok SAMBA ist da eine Katastrophe im Vergleich zu Solaris/Illumos/Windows)

Booten vom HBA ist kein Problem wenn man die Biosunterstützung nicht weggeflasht hat. IT und IR gehen beide problemlos mit ZFS sofern man kein Hardwareraid mit dem IR Mode macht.. SSD Trim soll mit IR Probleme bereiten können.

Konsistente SMB ACL Rechte geht eigentlich nur mit Illumos und Windows ohne Gewürge weil beide weltweit eindeutige (AD) SID als Security Referenz nutzen. SAMBA nutzt als Referenz einfache uid/gid Nummern. Die können auf jedem Server einen anderen Nutzer kennzeichnen. Das dann nötige Mapping uid <-> SID ist der Grund warum SMB Rechte unter SAMBA und Linux so kompliziert sind.
 
ob der HBA im IT Mode läuft...
Mensch jaaaaa! :d
1728522629161.png

Booten vom HBA ist kein Problem wenn man die Biosunterstützung nicht weggeflasht hat. IT und IR gehen beide problemlos mit ZFS sofern man kein Hardwareraid mit dem IR Mode macht.. SSD Trim soll mit IR Probleme bereiten können.
Erzähl mir mehr davon.

Die Sache ist ja auch eine grundsätzliche, vom HBA booten können zu wollen. Selbst wenn ich kein virtuelles TNS verwende sondern ne ZFS GUI auf Proxmox (was ich mir ja durchaus einreden lasse mal zu probieren, wenn ich etwas Zeit finde), benatwortet es ja die Frage ja nicht direkt... klar, man kann das umschiffen.
Nüchtern betrachtet kann ich den Bootvorgang auch händisch überwachen, wird nicht oft vorkommen... nur is dann halt kein Auto-Start bei Power-Loss. Meh.

Also nochmal, es funktioniert ja.

1. VM startet, Proxmox Logo
2. HBA initiallisiert, schreibt die HDDs auf, die davor hängen, sieht so aus:
1728523082833.jpeg
1728523055432.jpeg
3. Bild springt weiter, nicht erkennbar auf was. => Hier springt er wieder zu 1.
=> Das ist mein "Loop", in dem ich hänge (automatisch).

=> Aus diesem Loop kann ich manuell ausbrechen, indem ich bei:
1. dem Proxmox-Logo-Einschalt-Screen ESC drücke, dann kommt:
1.a. Ein Bootmenü mit den Einträgen "1. Legacy Boot ...", "2. QEMU ... irgendwas" (das virtuelle CD Laufwerk), "3. ..." (müsste diese Bios Shell sein oder so) - Wortlaut im Detail hab ich mir nicht gemerkt, kein Screen da ATM.
==> Wenn ich nun in 1.a. den Punkt 1 mit Enter auswähle, startet mir die Kiste, wie sie soll. Von der HDD am HBA, welcher im HBA-Bios entsprechend als Boot-Medium markiert ist.



Es funktioniert ja, nur nicht automatisch. Was übersehe ich?
 
der einzige Grund, warum ich TrueNAS einsetze ist, dass man hier recht einfach ein ISCSI-Target erstellen kann. Mehr aber auch nicht. Alleine, dass man keine Pakete installieren kann per Shell ohne alles zu zerschießen, ist ein NoGo für mich.
 
Mensch jaaaaa! :d
Anhang anzeigen 1034305


Erzähl mir mehr davon.

Die Sache ist ja auch eine grundsätzliche, vom HBA booten können zu wollen. Selbst wenn ich kein virtuelles TNS verwende sondern ne ZFS GUI auf Proxmox (was ich mir ja durchaus einreden lasse mal zu probieren, wenn ich etwas Zeit finde), benatwortet es ja die Frage ja nicht direkt... klar, man kann das umschiffen.
Nüchtern betrachtet kann ich den Bootvorgang auch händisch überwachen, wird nicht oft vorkommen... nur is dann halt kein Auto-Start bei Power-Loss. Meh.

Also nochmal, es funktioniert ja.

1. VM startet, Proxmox Logo
2. HBA initiallisiert, schreibt die HDDs auf, die davor hängen, sieht so aus:


3. Bild springt weiter, nicht erkennbar auf was. => Hier springt er wieder zu 1.
=> Das ist mein "Loop", in dem ich hänge (automatisch).

=> Aus diesem Loop kann ich manuell ausbrechen, indem ich bei:
1. dem Proxmox-Logo-Einschalt-Screen ESC drücke, dann kommt:
1.a. Ein Bootmenü mit den Einträgen "1. Legacy Boot ...", "2. QEMU ... irgendwas" (das virtuelle CD Laufwerk), "3. ..." (müsste diese Bios Shell sein oder so) - Wortlaut im Detail hab ich mir nicht gemerkt, kein Screen da ATM.
==> Wenn ich nun in 1.a. den Punkt 1 mit Enter auswähle, startet mir die Kiste, wie sie soll. Von der HDD am HBA, welcher im HBA-Bios entsprechend als Boot-Medium markiert ist.

Es funktioniert ja, nur nicht automatisch. Was übersehe ich?

Ich vermute, die 1. im Bios eingestellte Platte ist nicht bootfähig.

Wenn man von einem bootfähigen PCI Device z.B. einem HBA booten möchte (egal ob Proxmox barebone oder eine VM via passthrough) so muss man in den Bioseinstellungen (Mainboard oder VM) die entsprechende Platte als 1. Bootdevice einstellen.
Bei einem ZFS Softwaremirror die zweite Platte als 2. Bootdevice einstellen damit es davon bei Ausfall der ersten Platte davon bootet. Eventuell Sachen wie secure boot ausschalten und legacy+efi einstellen.

Bei einer VM sehe ich aber kaum einen vernünftigen Grund die direkt von Hardware zu booten statt von einer virtuellen Platte auf ZFS (mit Redundanz und Backup per Replikation).

Beitrag automatisch zusammengeführt:

der einzige Grund, warum ich TrueNAS einsetze ist, dass man hier recht einfach ein ISCSI-Target erstellen kann. Mehr aber auch nicht. Alleine, dass man keine Pakete installieren kann per Shell ohne alles zu zerschießen, ist ein NoGo für mich.
TN hält halt eine Datenbank mit eigener API für ZFS und Systemsachen. Da sollte man ausserhalb der GUI möglichst nichts machen. Ist für mich auch ein Nogo. Eine Web-GUI sollte transparent zu CLI Einstellungen arbeiten.

Aber wozu iSCSI? Ich versuche schon NFS zu vermeiden und damit geht vieles viel einfacher als mit iSCSI. Königsweg ist für mich SMB. Da geht Multiuser Access, saubere Rechtevergabe und es ist mit SMB Multichannel schnell, mit SMB direct sogar erheblich schneller als jede ip Methode (iSCSI, NFS, SMB) ohne RDMA.
 
Zuletzt bearbeitet:
Service läuft, Platte leer, System nicht ausgelastet. Ich glaube, es hat etwas mit meiner NAS zu tun welche ich lediglich am morgen für ein Backup starte. Habe schon sämtliche Workarounds durch, logs gelöscht etc.
Habe jetzt mal die Ordner in "/var/lib/rrdcached/db" gelöscht - mal schauen wies weitergeht..

Liegt wirklich am Backup - solange ich die NAS nicht starte, und Proxmox nicht auf PBS Nas Freigabe zugreifen kann, werden die Logs geschrieben. Kann mir da jemand helfen? Ich habe ehrlich gesagt keinen Plan wie ich das Problem lösen könnte.

Via influx und z.B. Grafana habe ich lückenlose Logs. Kann damit leben...
Hallo, ich wollte mich kurz zurückmelden, da ich nun eine Lösung habe.
Meine Syno startet täglich für 2 Stunden nur fürs Backup via PBS. Sobald die Nas offline ist, wurde die Summary nicht mehr geschrieben.

Mit dem folgenden crontab Eintrag kann das Problem dann gelöst werden. Mag für viele hier trivial sein, ich hab längere Zeit gebraucht, das Problem zu lösen ;)

Mounten vom volume namens pbs um 13:03, unmounten um 15:00 Uhr
3 13 * * * /usr/sbin/pvesm set pbs --disable 0
0 15 * * * /usr/sbin/pvesm set pbs --disable 1

3 13 * * * /usr/sbin/pvesm set synology-nas --disable 0
0 15 * * * /usr/sbin/pvesm set synology-nas --disable 1

Vielleicht hilfts jemandem weiter.
 
Wieso ist die EFBX als Boot-Laufwerk ausgewählt?
Wolltest du nicht von der SSD (BEKT) booten?
Hmmm, ich muss nochmal nachsehen. Danke für den Hinweis.

Könnte aber auch einen trivialne Grund haben:
Ich muss gestehen, ich hab die Screenshots jetzt aus einer Unterhaltung mit einem Kumpel genommen, möglicherweise ist der eine Screenshot vom schwarzen Init-Screen veraltet. Müsste ich nochmal prüfen.
Wollte um 3 in der Früh nicht nochmal alles hochfahren für Screens.
Ist btw. keine SSD sondern ne 250gb WD Black 2.5" Laptop-Festplatte, die lag grad rum, und für meine Test-Konfig reicht das ja... btw. läuft das NAS damit auch nicht schlechter.

Evtl. könnte ich noch testen die HDDs solang umzustecken bis mein Boot-Drive am Platz 0 liegt.

Ich vermute, die 1. im Bios eingestellte Platte ist nicht bootfähig.
Im Bios ist gar nix eingestellt, ich hab ja kein echtes Bios mit dem Sea-Bios, im UEFI sehe ich den Controller nicht.
die entsprechende Platte als 1. Bootdevice einstellen.
Hm, aber wenn das Bios nicht "hinter" den Controller sieht? Sollte es aber idR. wohl, oder? Hm.
Bei einer VM sehe ich aber kaum einen vernünftigen Grund die direkt von Hardware zu booten statt von einer virtuellen Platte auf ZFS (mit Redundanz und Backup per Replikation).
Hmja, ich versteh schon. Per Config File ist das ja alles schnell gemacht bei TrueNAS.


Ich wollte die Sache aber noch nicht ganz aufgeben, da ich es allgemein interessant finde, den originalen Datenträger in der VM zu booten.
Ich finde die Möglichkeit ganz hübsch.


Was ich eben nicht verstehe ist, warum es manuell geht, und automatisch in dieses Loop fällt.
Gibts in Proxmox irgend eine Start-Option, mit der ich das machen kann? Ich müsste der VM ja nur irgendwie mitteilen, dass sie im Sea-Bios-Bootmenü von 1. booten soll.... ich hab nur keine Ahnung wie das gehen könnte.
 
--- snip ---
Aber wozu iSCSI? Ich versuche schon NFS zu vermeiden und damit geht vieles viel einfacher als mit iSCSI. Königsweg ist für mich SMB. Da geht Multiuser Access, saubere Rechtevergabe und es ist mit SMB Multichannel schnell, mit SMB direct sogar erheblich schneller als jede ip Methode (iSCSI, NFS, SMB) ohne RDMA.
Um Blockgeräte durchzuziehen?
Versuche mal beispielsweise eine Steam-Bibliothek über SMB durchzureichen.
(Das ist mein UC für iSCSI)
ZVOL für iSCSI durchgereicht, auf dem Client mit ext4 formatiert und ganz normal gemountet.
Ich bezweifele, dass SMB da performanter ist, vor allem, bei vielen kleinen Dateizugriffen.

//Edith:
Also SMB abseits von Windows.
Oder geht SMB direct und SMB Multichannel mit TN, PX und Linux allgemein?
Hab bei ner schnellen Suche nur Kram für Windoofs gefunden...
 
Im Bios ist gar nix eingestellt, ich hab ja kein echtes Bios mit dem Sea-Bios, im UEFI sehe ich den Controller nicht.
Jede Virtualisierungsumgebung emuliert einen kompletten PC inkl Devices wie nic, Grafikkarte oder eben Bios.
Beitrag automatisch zusammengeführt:

Um Blockgeräte durchzuziehen?
Versuche mal beispielsweise eine Steam-Bibliothek über SMB durchzureichen.
(Das ist mein UC für iSCSI)
ZVOL für iSCSI durchgereicht, auf dem Client mit ext4 formatiert und ganz normal gemountet.
Ich bezweifele, dass SMB da performanter ist, vor allem, bei vielen kleinen Dateizugriffen.
Man muss da zwischen Sharing bzw Übertragungs Protokoll und Daten unterscheiden.
Prinzipiell ist iSCSI, NFS und SMB bei gleichen Einstellungen und Daten ähnlich schnell (z.B. sync). Performance bringt Multichannel bei allen und ganz besonders RDMA statt ip Transfers. Als Königsweg sehe ich da SMB direct/RDMA weil eben SMB auch ansonst überragende Features hat.
 
Zuletzt bearbeitet:
Jede Virtualisierungsumgebung emuliert einen kompletten PC inkl Devices wie nic, Grafikkarte oder eben Bios.
Beitrag automatisch zusammengeführt:


Man muss da zwischen Sharing bzw Übertragungs Protokoll und Daten unterscheiden.
Prinzipiell ist iSCSI, NFS und SMB bei gleichen Einstellungen und Daten ähnlich schnell (z.B. sync). Performance bringt Multichannel bei allen und ganz besonders RDMA statt ip Transfers. Als Königsweg sehe ich da SMB direct/RDMA.
Na das ist mir schon klar.

Wenn ich das richtig verstehe, ist das SeaBIOS eine "dünne" Version, bei der man eig. nichts einstellen kann, die idR. ausreichend ist und läuft.

Das virtuelle UEFI findet den HBA offenbar nicht, der ist in den Boot-Optionen da einfach nicht drin.
Zudem muss ich ja ein UEFI File anlegen. Müsste ich das eigentlich auf die UEFI-Partition der Boot-Disk verlinken? Zudem muss ich gestehen, dass mir da das Wissen fehlt, inwiefern der Maschienntyp 440i oder Q35 der richtige ist... und die damit verbundenen Optionen. Bin mit beidem nicht weiter gekommen.

Mich wundert eben hauptsächlich, warum das SeaBIOS wohl booten kann, allerdings nur manuell und nicht automatisch. Offenbar ist ja alles da, bis auf den Tastendruck.
 
@pwnbert:
1728554332749.png

Die Hilfe zu ProxMox hat dir nicht geholfen?
Also, unter Options die Boot-Order auf "hostpci0" zu stellen?
(In PX kannst die Reihenfolge per Drag'n'Drop ändern und die Hackeln bei den restlichen optional raus nehmen.)
hostpci0 sollte dein durchgereichter Controller sein.

(Jaja, süffisant, ich habs auch erst jetzt gefunden, an der Boot-Reihenfolge und deren Einstellungen bin ich auch schon oft gescheitert, weils versteckelt unter nem anderen Reiter ist... :fresse: )

//Edith:
Screenshot meiner Storage-VM:
1728554612717.png
 
Also, unter Options die Boot-Order auf "hostpci0" zu stellen?
Selbstverständlich hab ich das getan.
1728555969021.png
Ein kompletter DAU bin ich ja auch nicht - wobei - man kann schon ab und zu gut über "seine eigenen Füße fallen" :d... insofern ist mir natürlich jeder Hinweis recht.
 
So, die Sache ist erledigt.

Wenn ich kein Bootdevice angebe, funktioniert es. Macht ihmo einfach keinen Sinn, aber ist halt mal so.

1728594540712.png

1728594635139.png
1728594744704.png

------------------------------
Daraus entsteht aber ein neues Problem, weil:

Der Witz dran ist, ich bin draufgekommen, weil ich von einer EndeavourOS VM starten wollte, mit dem Controller drin, um nach dessen Bios Updates zu schauen.
Sobald er durchgereicht war, wurde davon gebootet (auch wenn ich den ihn gar nicht ausgewählt habe in der Bootliste sondern das eOS).

1728595749033.png
Lustig, wenn ich hier jetzt:
1 wähle, wo das eOS drauf liegt, startet er trotzdem vom HBA das TrueNAS.
2 wähle, startet er vom HBA das TrueNAS
3 wähle, startet er in den Installer von eOS (das Iso ist noch eingehängt), wähle ich dort "boot existing OS", wird vom HBA gestartet
4 wähle, findet er natürlich kein Netzwerk-Ding und startet vom HBA
=> Mit dem HBA drin hab ich irgendwie keine Möglichkeit vom VirtIO SCSI zu starten...
------------------------------
Auch die Sache ist geklärt. Das tritt auf, wenn "rombar=1", mit "rombar=0" geht es, wie es soll. Im OS finde ich den Controller mit lspci, mit lsblk finde ich die HDDs die dran hängen.
Das von oben nochmal getestet, mit "rombar=0" fällt er mir ins "bootloop", mit "rombar=1" startet er vom Controller.


What a ride. :fresse2:
------------------------------
tl,dr:
Wenn man vom HBA booten will, braucht man offenbar "rombar=1", dazu ein leeres (!) Bootmenü in Proxmox.
Wenn man "normal" ne VM starten will und drin die Disks am HBA verwenden, braucht man offenbar "rombar=0" und ein entsprechendes virtuelles Laufwerk mit OS zum booten wie üblich.
 
Auch die Sache ist geklärt. Das tritt auf, wenn "rombar=1", mit "rombar=0" geht es, wie es soll. Im OS finde ich den Controller mit lspci, mit lsblk finde ich die HDDs die dran hängen.
Das von oben nochmal getestet, mit "rombar=0" fällt er mir ins "bootloop", mit "rombar=1" startet er vom Controller.


What a ride. :fresse2:
------------------------------
tl,dr:
Wenn man vom HBA booten will, braucht man offenbar "rombar=1", dazu ein leeres (!) Bootmenü in Proxmox.
Wenn man "normal" ne VM starten will und drin die Disks am HBA verwenden, braucht man offenbar "rombar=0" und ein entsprechendes virtuelles Laufwerk mit OS zum booten wie üblich.
Ich kenne diese Problematik auch. Nochmals zur Sicherheit. Was gibt dir dein HBA aus, wenn du folgendes in Proxmox eingibst?
lspci -nnk -s 01:00.0 (falls es bei dir eine andere ID ist entsprechend ändern.)

Falls dies hier kommt: Kernel driver in use: mpt3sas

Dann Treiber auf Blacklist setzten oder an vfio-pci fest anbinden. Dann sollte er sowohl mit rombar=1 in der VM booten. ;)

Ich hätte hie rauch noch eine Frage an die Proxmox Experten die TrueNAS virtualisiert nutzen:
Also Machine natürlich q35 und UEFI, wegen PCIe Passthrough, aber gibt es sonst noch wichtige Settings um einen "langjährigen" problemlosen Betrieb zu sichern?
 
Also Machine natürlich q35 und UEFI, wegen PCIe Passthrough
Weiss nicht, 440 tuts bei mir. Hab gelesen, wenns mit 440 überhaupt läuft, dann läufts auch gut. Wo anders (n blog) hab ich gelesen, dass q35 wohl weniger CPU Last im Idle macht, inwiefern das verifizierbar ist?

TrueNAS ist so gutmütig, dass die Installation sowohl von VM als auch baremetal bootet, also treibermäßig und so beim Start. Würd mir da keine großen Sorgen machen.
 
---snip---
Ich hätte hie rauch noch eine Frage an die Proxmox Experten die TrueNAS virtualisiert nutzen:
Also Machine natürlich q35 und UEFI, wegen PCIe Passthrough, aber gibt es sonst noch wichtige Settings um einen "langjährigen" problemlosen Betrieb zu sichern?
Bin zwar kein Experte, aber: regelmäßig Updates machen soll helfen. =)
Spaß beiseite:
1728721635499.png
1728721693902.png

Mit den Einstellungen läufts seitdem ich auf ProxMox umgestiegen bin (kurz nach dem Broadcom-Desaster von VMWare).
Der Daten-Pool läuft aber schon seit meinem Umstieg von TN legacy (BSD) auf TN Scale.
Also seit ziemlich genau einem Jahr (der Report ist schon etwas älter):
1728721838889.png

Die SSDs vom System-Pool (auf dem auch Nextcloud seine Daten ablegt) laufen schon seit 3 Jahren, den Pool hatte ich damals nicht verschlüsselt und einfach so von legacy auf Scale rüber gezogen.

//Edith:
Zur Info:
Daten-Pool issn RAID-Z2 mit 48 TB, System-Pool issn Mirror mit 1 TB.
 
@Weltherrscher: Steam war bei mir auch Hauptgrund für iSCSI. Installverzeichnis auf SMB-Share klappte mit einigen Spielen einfach nicht (damals vor diversen Jahren). iSCSI ist für alle Zwecke hinter dem OS „lokal“, damit kann man dann jede Anwendung täuschen. ;)

Ob das heute auch noch so ist, weiß ich allerdings nicht.
 
Ist noch so.
Und Steam Linux ist noch schlimmer, das will ne ext4-Partition (für die Rechteverwaltung) haben...
 
Will es ext4 oder will es nur kein NTFS?
Also, wie wärs mit btrfs?
 
Geht definitiv, ist bei mir schon quasi seit immer btrfs
 
Wasserstandsmeldung:
1729006738496.png

NIIICE. =)
Zunächst im px2, die Concorde im Keller wollte ich noch nicht aufschrauben, (WAF derzeit < 0).
Kommt aber spätestens morgen Nacht unten rein.
 
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