PCI Passthrough in Proxmox 8.0 auf TrueNas Scale funktioniert nicht

Sandolo

Neuling
Thread Starter
Mitglied seit
28.09.2023
Beiträge
47
Ort
Berlin
Leider komme ich einfach nicht weiter. Entweder gibt es nur halbe Erklärungen oder sie sind auf Englisch (was ich nun nicht so beherrsche). Vermutlich basieren viele Guides auch nur auf HörenSagen.

System:
Asus Prime X370-Pro (aktuelles UEFI)
- SVM aktiviert
- IOMMU aktiviert
Ryzen 7 5750G
512GB NVME als Systemplatte für OS und VM
Software:
Proxmox 8 als OS (aktuelles Update)
TrueNas Scale als VM (aktuelles Update)

Einstellungen in Proxmox:

nano /etc/kernel/cmdline
root=ZFS=rpool/ROOT/pve-1 boot=zfs amd_iommu=on iommu=pt
Screenshot (269).png

nano /etc/ moduls
vfio
vfio_iommu_type1
vfio_pci
vfio_virqfd
Screenshot (270).png

nano /etc/default/grub
wahlweise
GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on"
oder
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
Screenshot (271).pngScreenshot (274).png

Bis hierher auch alles normal / ok.

Abschließend noch folgende Eingaben gemacht:

proxmox-boot-tool- refresh
und
update-initramfs -u -k all

und hier kommen die ersten Fehlermeldungen. Bei beiden Eingaben kommt:

No /etc/kernel/proxmox_uuids found, scipping ESP sync.
Screenshot (273).png

Bis hier lässt sich TrueNas auch noch starten.
Aber sobald ich den SATA-Controler in Proxmox an TrueNas durchreiche, hängt sich alles auf.

Ich weiß jetzt nicht mehr weiter und hoffe, dass es hier noch jemanden gibt, der was von der Materie versteht.
Ansonsten werde ich wohl statt zu Linux komplett zu wechseln, komplett auf kommerzielle Lösungen von MS setzen müssen.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ohne mich jetzt tiefer mit Proxmox auseinander gesetzt zu haben: das durchreichen von onboard Controller, gerade auch mit Consumer Hardware, ist Glücksache. Daher nutzen die meisten einen HBA fürs Storage.

Der onboard SATA Controller dürfte zudem über den Chipsatz angebunden sein, was das ganze auch nicht einfacher macht.
 
Ja. Der SATA-Controler hängt am Chipsatz, "shared" aber mit sonst nichts.
Ich habe aber auch den HBA am PCIe 2 x4 (ASM-1166) versucht durchzureichen. Genau das selbe Problem.

Ich vermute, es muss mit der Fehlermeldung beim Boot-Loader "No /etc/kernel/proxmox_uuids found, scipping ESP sync." zusammenhängen.
 
Da ich von Proxmox keine Ahnung habe, würde ich es kurz mit ESXi gegentesten. Wenn Du den Controller dort durchreichen kannst, das geht völlig schmerzlos, hast Du schon mal die Gewissheit, dass es gehen würde.
 
Zuletzt bearbeitet:
Ich werfe mal den Begriff IOMMU-Group in den Raum. Je nach Board kann es sein, dass die ganze Gruppe durchgereicht wird und dann steht der Host nackig da.
Schau doch mal, was alles drin ist.
Genauso ist es. Es liegt an der IOMMU-Gruppierung. Der Controller sitzt mit mehreren Geräten in einer Gruppe.
Allerdings sitzt dort auch mein HBA, so dass auch ein separater Controller wohl keine Abhilfe schafft.

Daher werde ich mir eine separate SSD nehmen und TrueNas aufs Blech setzen.
 
Zusätzlich ist es aber auch möglich die Festplatten einzeln per UUID durchzureichen statt den gesamten Controller
Ja, RDM heisst das bei ESXi. Aber ob man sich das bei einem Filer mit 8 (Consumer-) SSD antun will? Aber wäre eine Möglichkeit.
Beitrag automatisch zusammengeführt:

@Sandolo : welcher HBA sitzt denn an Deinem Chipsatz? Der SATA Controller? Hast Du den PCIe 16x, wo die GPU stecken würde, denn noch frei? Dann würde ich mir einen echten HBA mit 2 oder 4 SAS Buchsen holen.

Und wenn Du schon proxmox nutzt. Habe ja selbst wie gesagt keinen Plan. Aber wieso nutzt Du nicht das ZFS von Proxmox, und willst da was mit TrueNAS basteln? Das ist ja gerade einer der grossen Vorteile von Proxmox, so wie ich verstanden habe. Da hast Du Storage schon an Board.

Mit der Hardware würde ich definitiv auf einen baremetal Hypervisor setzen. Reines NAS geht auch einfacher.
 
Zuletzt bearbeitet:
Platte als RAW Device in die VM:



# devices auflisten / identifizieren

ls -la /dev/disk/by-id/

/dev/disk/by-id/ata-SAMSUNG_MZ7L31T9HBLT-00A07_S6ESNC0TB12345


# device der VM zufügen
> qm set 100 -scsi1 /dev/disk/by-id/ata-SAMSUNG_MZ7L31T9HBLT-00A07_S6ESNC0TB12345

// 100 = VMid / scsi1 = nächster freie Plattennschluss oder was auch immer der näcshte freie sein soll

danach noch setzen: discard + ssd emulation = on

dann im gui prüfen / aktualisieren + fertig.
 
@Sandolo : welcher HBA sitzt denn an Deinem Chipsatz? Der SATA Controller? Hast Du den PCIe 16x, wo die GPU stecken würde, denn noch frei? Dann würde ich mir einen echten HBA mit 2 oder 4 SAS Buchsen holen.

Und wenn Du schon proxmox nutzt. Habe ja selbst wie gesagt keinen Plan. Aber wieso nutzt Du nicht das ZFS von Proxmox, und willst da was mit TrueNAS basteln? Das ist ja gerade einer der grossen Vorteile von Proxmox, so wie ich verstanden habe. Da hast Du Storage schon an Board.

Mit der Hardware würde ich definitiv auf einen baremetal Hypervisor setzen. Reines NAS geht auch einfacher.
Also, ich habe einen PCIe x4 SATA-Controller für 4 SATA-Anschlüsse am PCIe 2.0 x16-Slot (HBA). Das Board hat 8 SATA-Ports ohne Sharing.
Für meinen DatenPool habe ich acht SSDs. Deswegen sollten diese an den boardeigenen Controller.

Proxmox ist sicher für VMs und Container besser als TrueNas, aber nicht als Storage.
TrueNas bietet mir zudem die Möglichkeit zu einem RaidZ 2 noch eine Hot Spare-Platte mit einzubinden, was Proxmox auch nicht kann. Letztlich gibt es noch keine Möglichkeit mit Proxmox (auch PBS nicht) BackUps von Windows-Clients aufzusetzen, was aber mit TrueNas geht.

Mein Hauptanliegen ist das NAS. Dazu kommen 4 weitere VMs, die als Testcenter/Versuchslabor dienen (Win 11, Win 10, Win Server, Linux Mint) und ein paar Container (Vaultwarden, PiHole, Tarpit, Wireguard, etc.) und wahrscheinlich Jellyfin als MediaServer. Für Jellyin habe ich noch eine separate 2 TB SSD am HBA. Dazu hängen am HBA noch zwei Wechselrahmen (1 x 2.5 / 1 x 3,5). Am letzten Port des HBA hing ein DVD-LW. Dieses habe ich jetzt raus und dafür eine 120GB-SSD für das TrueNas-OS. Auf die 512GB-NVMV kommen dann die VMs und Container.

Ich habe das irgendwo auch schon mal geschrieben. Der Server steht in der Wohnung. Muss also leise und eine All-in-One-Lösung sein.
Ich wollte das Beste aus Proxmox und TrueNas, was leider bei mir so nicht möglich ist. Mit der separaten OS-SSD ist TrueNas für mich die bessere Lösung.

LSI/SAS-Controller für die PCIe x16-Slots sprengen mein Budget, was durch die SSDs schon arg überzogen ist.

Platte als RAW Device in die VM:



# devices auflisten / identifizieren

ls -la /dev/disk/by-id/

/dev/disk/by-id/ata-SAMSUNG_MZ7L31T9HBLT-00A07_S6ESNC0TB12345


# device der VM zufügen
> qm set 100 -scsi1 /dev/disk/by-id/ata-SAMSUNG_MZ7L31T9HBLT-00A07_S6ESNC0TB12345

// 100 = VMid / scsi1 = nächster freie Plattennschluss oder was auch immer der näcshte freie sein soll

danach noch setzen: discard + ssd emulation = on

dann im gui prüfen / aktualisieren + fertig.
Vom Durchreichen einzelner Disk wurde mir mehrfach abgeraten. Insbesondere, weil es sich hier um acht Stück handelt.
 
Proxmox kann vieles, nur nicht zwingend über die GUI. Am Ende ist nen Debian drunter. Also: Notfalls installierst du dir Samba und Co dazu. Was du mit ZFS machen willst, geht über die Console: Egal ob Cache-SSD oder ne Spare-HDD. Die Funktionen sind per se dabei (über die Befehle zfs und zpool).
Bei meinen Eltern hab ich ne ASRock Beebox. Proxmox drauf, nen paar VMs (Adguard, Unifi-Controller) und die Freigabe auf ner extra Platte.
Ne Eierlegende Wollmilchsau wirst du nicht zwingend finden; Abstriche gibt's bei soviel Anforderungen eben. Aber TrueNAS will RAM. Wenn du das als VM-Host nutzen willst, geht das immer zulasten der Reaktionszeiten für die Daten. Dann lieber das Debian unterm Proxmox mit Zusatzfeatures pimpen.
Ebenfalls möglich, aber etwas um die Ecke gebogen, wäre die Option, den ZFS-Datenpool als Freigabe per iscsi oder NFS nativ über die Eigenschaften des Pools zu ermöglichen und das Ganze dann in ner VM abzugreifen und darüber dann die Benutzer, Rechte, etc. verwalten. Geschickt gefädelt bleibt der Datenstrom sogar innerhalb des Hosts und muss nicht erst über nen Switch. Aber das artet dann schnell aus, was die Komplexität angeht.
 
Proxmox kann vieles, nur nicht zwingend über die GUI. Am Ende ist nen Debian drunter. Also: Notfalls installierst du dir Samba und Co dazu. Was du mit ZFS machen willst, geht über die Console: Egal ob Cache-SSD oder ne Spare-HDD. Die Funktionen sind per se dabei (über die Befehle zfs und zpool).
Bei meinen Eltern hab ich ne ASRock Beebox. Proxmox drauf, nen paar VMs (Adguard, Unifi-Controller) und die Freigabe auf ner extra Platte.
Ne Eierlegende Wollmilchsau wirst du nicht zwingend finden; Abstriche gibt's bei soviel Anforderungen eben. Aber TrueNAS will RAM. Wenn du das als VM-Host nutzen willst, geht das immer zulasten der Reaktionszeiten für die Daten. Dann lieber das Debian unterm Proxmox mit Zusatzfeatures pimpen.
Ebenfalls möglich, aber etwas um die Ecke gebogen, wäre die Option, den ZFS-Datenpool als Freigabe per iscsi oder NFS nativ über die Eigenschaften des Pools zu ermöglichen und das Ganze dann in ner VM abzugreifen und darüber dann die Benutzer, Rechte, etc. verwalten. Geschickt gefädelt bleibt der Datenstrom sogar innerhalb des Hosts und muss nicht erst über nen Switch. Aber das artet dann schnell aus, was die Komplexität angeht.
Wie gesagt. Ich bin in Sachen Server und Linux absoluter Neuling. Die oben gezeigten Shell-Befehle sind so ziemlich die einzigen, die ich bisher kenne. Daher muss erstmal viel über das GUI laufen. Wie es später aussieht, wird man sehen. Eine Spare-Funktion habe ich in Proxmox nicht gefunden und auch nirgends was in einem Guide gelesen. Eine Cache-SSD ist nicht nötig. Bringen die SSDs für den DatenPool selbst mit.

VMs laufen auch nur bei Bedarf, wenn ich was testen möchte. Was die Container betrifft (denke mehr als 10 werden es auch nicht), muss ich sehen, wie sich TrueNas schlägt.
Letztlich fehlt Proxmox einfach die Möglichkeit, ein BackUp für externe Windows-Clients zu sein.

Mit 64GB denke ich ausreichend RAM für TrueNas zu haben.
 
Mach ihm doch keine Angst. Mit 64 GB kommt man schon sehr weit. Solange man keine Deduplikation verwendet, reichen auch ein paar GB für den Filer.

Wobei TrueNAS glaube ich schon echt Ressourcen haben will. Aber bei 64 GB kein Thema.
 
Ich habe TrueNAS mit 2GB oder 4GB RAM betrieben. Das reicht völlig aus.
Man darf nicht vergessen, dass der Kollege hier wohl kaum ein KMU führt, wo mehrere hundert Clients drauf rumtrommeln, damit man solche Mengen RAM sinnvoll begründen kann.
Mehr geht immer, das ist klar, kostet aber auch Geld und Strom und damit wieder Geld.
Und solange man nicht mit der Kiste nicht Virtualisieren will, kommt man (ggf. grade so) auch mit 4GB hin, denke ich.
 
Ich habe TrueNAS mit 2GB oder 4GB RAM betrieben. Das reicht völlig aus.
Man darf nicht vergessen, dass der Kollege hier wohl kaum ein KMU führt, wo mehrere hundert Clients drauf rumtrommeln, damit man solche Mengen RAM sinnvoll begründen kann.
Mehr geht immer, das ist klar, kostet aber auch Geld und Strom und damit wieder Geld.
Und solange man nicht mit der Kiste nicht Virtualisieren will, kommt man (ggf. grade so) auch mit 4GB hin, denke ich.
Ja, ich hab auch nen TrueNAS mit deutlich weniger laufen, aber "Genügend RAM" heißt für mich mehr bringt keine Leistungszuwächse mehr - und das muss ich noch schaffen, meine Versuche sind bis 512 GB gegangen, und das hat gegenüber 256 immer noch Performance gebracht. Getestet hatte ich mit 2 4K Videostreams und 3 Kopieraktionen von 3 Clients. Kein KMU, aber 5-köpfige Familie.
 
Aber den PCIe_1 x16 hast Du noch frei? Den HBA kriegst Du mit samt Kabeln und Versand vom China Mann für unter EUR 30.-, das sollte ja noch drin liegen?

Leider will der Chinamann bei uns schon 47,- € pro Stück.
Und dann bin ich nicht mal sicher, ob ich bei meinem Board nicht wieder mehrere Komponenten in der Gruppe habe. Hinzu kommt, dass ich Elektronik nicht direkt aus China kaufe. Mal ein Kabel, aber das wars dann auch schon.
Und was mache ich dann mit den Komponenten, die ich jetzt schon habe? Ich habe dann ne Sammlung von SATA-Controllern. Letztlich spielt da auch noch die Optik mit rein. Kannst du bei mir Fetisch nennen, aber ist mir wichtig. Und eine grüne Platine schreckt mich da schon ab.
DSC_0384.JPG

There is no such thing like "Genügend Ram für ZFS" - der RAM ist der Lesechace, mehr ist immer besser.
Mach ihm doch keine Angst. Mit 64 GB kommt man schon sehr weit. Solange man keine Deduplikation verwendet, reichen auch ein paar GB für den Filer.

Wobei TrueNAS glaube ich schon echt Ressourcen haben will. Aber bei 64 GB kein Thema.
Ja, ich hab auch nen TrueNAS mit deutlich weniger laufen, aber "Genügend RAM" heißt für mich mehr bringt keine Leistungszuwächse mehr - und das muss ich noch schaffen, meine Versuche sind bis 512 GB gegangen, und das hat gegenüber 256 immer noch Performance gebracht. Getestet hatte ich mit 2 4K Videostreams und 3 Kopieraktionen von 3 Clients. Kein KMU, aber 5-köpfige Familie.

Was solls, wenn das Board nur max. 64 GB kann...

Wie gesagt. VMs laufen bei mir nur einzeln und nach Bedarf. Dazu ne Handvoll Container plus Medienserver. Der Rest ist BackUp / Datensicherung von insgesamt fünf Rechnern, inklusive des Servers und zwei Usern.
 
Zuletzt bearbeitet:
There is no such thing like "Genügend Ram für ZFS" - der RAM ist der Lesechace, mehr ist immer besser.

ZFS cacht ZFS Datenblöcke mit einer read last/read most Optimierung, keine Files. Mit wenig Usern und wenig aktiven Files bedeutet das dass man mit ausreichend RAM z.B. 64GB (Solaris etwas weniger) Arc Cache-Hit Raten von >80% erreicht. Wenn mehr RAM dann bedeutet dass die Cache Hitrate auf 85% steigt so wird das keinen spürbaren Unterschied machen.

Anders sieht es aus wenn man sehr viele User und sehr viele sich schnell ändernde kleine Files hat z.b. großer Mailserver. Dann bringt allein das Cachen der Metadaten und aktiven kleinen Blöcke mit Textdaten sehr viel und 128+ GB RAM machen Sinn genau wie ein optionales zusätzliches L2Arc vor allem weil das persistent ist sowie read ahead kann und nicht erst lange angelernt werden muss wie der Arc. Mit üblichen Uptimes sollte das aber auch keinen großen Unterschied machen.

Den größten Performanceschub merkt man unterhalb 32GB (2GB->4GB->8GB->16GB->32GB) mit abnehmender Tendenz wobei man mit Linux nicht unter 8GB gehen sollte. Dazu ist RAM ja auch Schreibcache (10% RAM, max 4GB als default) und dafür möchte man auch gerne 1GB+ (Abhängig von Anzahl aktiver User, je mehr User desto mehr bringts der Extra RAM)
 
Zuletzt bearbeitet:
JFYI, AM4 und der 5750G können generell 128GB, nicht nur 64GB.
Ob es mit Vollbestückung (4x32GB Dual-Rank Module) spezifisch auf dem eingesetzten Board Probleme gibt, kann ich natürlich nicht sagen.
Generell sollte man die Timings da natürlich etwas entspannter ansetzen, als manche das bei der Jagd nach den letzten FPS tun.

Meine beiden 128GB-Kisten (allerdings Vermeer, nicht Cezanne) stehen da auf 3200CL22 und 1,2V, so wie es die entsprechenden ECC-Module standardmässig auch vorsehen (sind Kingston Server Premier mit Micron E-Die).
Der 5750G im Hauptsystem hat 4x16GB drin (2666er original Samsung ECC Module mit B-Dies @ 3200CL18 @ 1,38V).
 
Zuletzt bearbeitet:
JFYI, AM4 und der 5750G können generell 128GB, nicht nur 64GB.
Ob es mit Vollbestückung (4x32GB Dual-Rank Module) spezifisch auf dem eingesetzten Board Probleme gibt, kann ich natürlich nicht sagen.
Generell sollte man die Timings da natürlich etwas entspannter ansetzen, als manche das bei der Jagd nach den letzten FPS tun.

Meine beiden 128GB-Kisten (allerdings Vermeer, nicht Cezanne) stehen da auf 3200CL22 und 1,2V, so wie es die entsprechenden ECC-Module standardmässig auch vorsehen (sind Kingston Server Premier mit Micron E-Die).
Der 5750G im Hauptsystem hat 4x16GB drin (2666er original Samsung ECC Module mit B-Dies @ 3200CL18 @ 1,38V).
Mmh. Ich sitze hier gerade immernoch mit weit geöffnetem Mund.
Denn ich bin davon ausgegangen, dass beim Asus Prime X370-Pro der Chipsatz die Kapazität begrenzt. Nicht nur weil es im Handbuch steht, sondern auch bei Asus auf der Homepage, so manchen Speicher-Hersteller wie Crucial u.s.w. Bevor ich aber meine große Klappe aufreiße, dachte ich, schau doch mal was die PowerShell sagt. Und ich hab mich echt auf den Arsch gesetzt. Das Board (System mit 5750G) macht tatschlich 134217728 KB.

Wieder was gelernt. Vor allem, verbreite nur das, was du selbst überprüft hast ...

Nichts desto Trotz, werde ich mit 64 GB erstmal auskommen müssen. (Sagt mein Finanzminister mit Ring am Finger)
 
Kein Problem. :-)

Denke das ist einfach auch dem Alter des Boards geschuldet, die 300er Chipsätze waren ja die "Erstlinge" und 128/4x32 GB waren damals doch recht unübliche Speichermengen für Endkundensysteme und daher vmtl. schlicht nicht aufgeführt. Wenn 32er Udimm-Module überhaupt schon bezahlbar erhältlich waren.

Ähnlich ist es ja oft auch für Notebooks. Mein Probook x360 435 G8 (5800U) z.b. sagt: "max 32GB, 2x16GB So-Dimms" im Datenblatt von HP. 2x32GB 3200er laufen aber auch völlig fehlerfrei und rock stable.
 
Das ist völlig normal. Die Max-Module kommen ja immer erst am Ende einer RAM-Generation.
Das testet dann kein Hersteller mehr rekursiv. Das macht man dann nur noch für aktuell laufenden Produkte.
Wichtig ist dann, dass man das neuste BIOS drauf hat und auch mal gewillt ist, ein wenig mit den Einstellungen zu spielen.
 
Genauso ist es. Es liegt an der IOMMU-Gruppierung. Der Controller sitzt mit mehreren Geräten in einer Gruppe.
Allerdings sitzt dort auch mein HBA, so dass auch ein separater Controller wohl keine Abhilfe schafft.
Und? Was ist dabei rausgekommen?

Ich plane mein TrueNAS in absehbarer Zeit auf einen Proxmox Unterbau zu verschieben.
Hab auch einen 5750G und dazu ein B550 Board.


Ich werd wohl einen HBA brauchen... 8 Ports müssten eigentlich reichen.
=> Gibts da eine Erfahrung, was funktioniert?
Was kauft man, was ist zuverlässig und sparsam? So ein paar Dell, LSI usw. bekommt man ja im "angenehmen" Preisbereich auf Ebay. Gibts da aktuell Empfehlungen?

Besonders gut gefallen würde mir natürlich was mit PCIe 3.0x4 und kein PCIe 2.0x8, würde die Sache flexibler machen. Muss aber nicht sein.
 
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