WowaDriver

What do you mean with „once it’s up and running“? Do I not have the possibility to shut down the vm‘s?

Hey @all, do i understand it right... whit this plugin i can virtualize the uhd 770 of an 13900k to many vm's i want and can also use it simulantiously in the dockers like emby and plex?

Statusupdate: @DataCollector: zu a) ja das ist richtig und ich nutze Unraid nicht wegen den von dir o.g. Gründen im Bezug auf das klassische Array von Unraid. Hierfür habe ich einen kleinen Stick 8-16Gb zugewiesen und alles vom Array ausgelagert. Der dümpelt leer vor sich hin, nur damit das "Unraid Array" startet. zu b) Ich habe mich mit Unraid schon so dermaßen angefreundet, dass ich nichts anderes mehr möchte. Ich habe mich bewusst für Unraid entschieden weil ich es als Hypervisor für meine VM's und Docker Container nutze. zu c) da bin ich dran und das soll wohl gehen, aber aktuell legt sich beim zfs pool noch nicht selbstständig schlafen. Und zu meinem Anliegen allgemein und als Lösung: Das native ZFS Dateisystem in Unraid läuft so wie ich es auch gelesen habe mit der Auto Expand Funktion. Wichtig ist nur man muss anfangs beim Erstellen des Pools festlegen wieviel Platten man eben in einem raidz fahren möchte. Ich wollte unbedingt 8 Platten (7+1 Parity) und habe somit 6x18TB und zwei alte 2x8TB Platten verbaut. Das raidz wurde somit auf knappe 56TB erzeugt was somit 7x8TB entspricht und auch logisch ist, da wie bei Raid 5 die größeren Platten das Niveau der kleinsten Platte einnehmen. Nachdem alle Daten rüber geschaufelt worden sind, habe ich erstmal eine 8Tb Platte gegen eine neue 18TB Platte getauscht. Folgedessen ist das raidz 2degraded" bzw. abgestürzt und hat die neue 18TB "resilverd" bzw. das raid neu aufgebaut. Das hat bei einer 18Tb Platte nur etwa 6 Std. gedauert. Bei meinem alten Raid 5 mit 8x6Tb Platten hatte das etliche Tage gedauert. Anschließend das gleiche für die letzte Platte wiederholt und als der Resilverungs Porzess durchgelaufen ist, hat sich das maximale Volumen des Pool auf 122TB erhöht. Somit alles so wie es soll und gewollt war. Danke für das Lesen meiner Problem. Mir war eigentlich klar, dass es so kommt wie es gekommen ist, ich wollte mich eben nur einmal absichern bevor ich den Schritt gegangen bin.

Ja das ist mir klar und ich habe auch vor ZFS in einem seperaten Pool einzusetzen. Ein Unraid Array für Daten habe ich gar nicht. Ich gehöre zum Team RAID5 und Synology. Hatte dies ca. 4 Jahre als VM auf Unraid laufen mit den 8 Platten als RAID5, weil dies in Unraid so eben nicht nutzbar war. Jetzt wo ZFS da ist möchte ich die Vorteile eines RAID5 mit denen eines ZFS Pool kombinieren. Build und Rebuild Zeiten und vor allem Zugriffszeiten via 10GbE ohne NVMe Cache. Ziel ist es auch diesen ZFS Pool dann bei nicht Zugriff in den Schlafmodus gehen, das was ich gelesen habe soll dies ja möglich sein. Dann wäre das stromspar Potenzial auch gegeben, auch wenn nicht so wie bei einem klassischen UNraid Array, bei dem ja auch nur die Platte angesteuert wird, die eben benötigt wird... das ist auch eher sekundär Ziel. Ich greife wenn auf das Storage zu mit großen Daten Mengen und da ist der Cache Speicher schnell mal eben voll... Somit finde ich ein RAID5 bzw. jetzt ein raidz1 besser geeignet. Das mit dem Erweitern habe ich ja durchgespielt nur will ich das mit den produktiv Platten nur machen wenn ich mir 100%ig sicher bin das es klappt, dashalb die Frage an die Community.

Hi again, niemand einen Ratschlag für mich ob ich mit meinem Vorhaben richtig fahre? Gruß

Hallo @all, ich möchte das neue native Dateisystem in Unraid als raidz1 mit 8 Platten nutzen. Ich habe von 8x6TB die voll waren auf 8x18TB aufgerüstet und alle Daten des alten RAID5 aus einem Synology System auf 2 der 18TB Platten zwischen gespeichert. Mangels Unwissenheit war mein Plan ursprünglich so (ich nahm an eine raidz1 zfs Erweiterung verhält sich wie ein RAID5): 1. raidz1 mit 6 Platten aufsetzen 2. die Daten von den zwei übrigen Platten rüber spielen 3. die beiden übrigen Platten dem raidz1 hinzufügen. Ende vom Lied, geht nicht! Ich kann immer nur das erweitern was ich anfangs erstellt habe. Sprich 6 Platten (5+1) also als nächstes nochmal 6 Platten (5+1) eben. Oder eben 4 Platten (3+1) und das ganze dann nochmal. Jedoch möchte ich keine zwei Paritätsplatten haben. Mir reicht eine. Der wichtigste Content ist eh mit 6 TB doppelt und dreifach gesichert. Nun zum Problem und meiner Idee dieses zu lösen. Ich habe testweise ein raidz1 mit 8 Platten (4x18TB und 4x1TB) aus alten Platten aufgebaut um zu erzwingen, das er ein raidz1 mit 8 (7+1) Platten erstellt. War dann natürlich mega klein. Ich habe Testdaten drauf geschaufelt und anschließend, nacheinander erst eine 1TB Platte gegen eine 18TB getauscht und dann die andere. Ende vom Lied, Daten waren noch drauf und er hat die 18TB Platten angenommen und die Poolgröße automatisch erweitert. Nun würde ich das ganze eben auch gerne mit den realen Daten machen. Also ein raidz1 aus 6x18TB und 2x8TB aufbauen (56TB) die produktiven Daten rüber schaufeln und anschließend die beiden 8TB Platten gegen die übrigen beiden 18TB Platten tauschen. Der Test war erfolgreich nur hab ich bisschen schiss das produktiv umzusetzen mangels Erfahrung mit zfs... ich wollte mir das Vorgehen gern von euch bestätigen lassen. Ich würde gerne andere Wege gehen, habe aber knapp 32TB Daten und nur alternativ 12TB an alten Festplatten liegen. Das RAID5 aus 8x6TB musste leider zeitnah gehen um die neuen Platten holen zu können. Sonst hätte ich beide Pool parallel laufen lassen und das zfs Pool sauber erstellt und die Daten migriert. Killt mich bitte nicht für meine Idee falls diese blödsinn ist. Bin für jeden Tipp dankbar! Beste Grüße

Hi @all, i want to use a virtual vmxnet3 interface for my xpenology vm. Principally it works, but the interface is shown as an normal 1 gig interface and not like it should be as a 1 gbe interface. The correct drive for the vm is loaded. Do I have to make some setting on the Unraid base? My unraid server is connected with 1x RJ45 10 GBe onboard nic and 2x SFP+ mellanox connect x3 port physically. So here it shouldn't be a problem.... It would be really cool if somebody can give me a tip. Thanks!

Maybe you are right, but the only power saving settings I found are these both and they are disabled... All three ASPM Settings are manually off and the LPM Support too Do you have an other idea?

Ja gut das ginge dann wohl immer hätte aber den Nachteil das es qmu drives währen und ich die Smart Werte nicht durchreichen könnte. Performance technisch wäre es wohl auch etwas schlechter. misst würde gerne das pci device durch reichen.

Hi @all, my mainboard is a Gigabyte z590 Aorus Master which has 3x mechanical x16 PCIe Ports. The first and the second one is connected to the CPU and the third to the chipset. For the first both i can configure the bios to these bifurcation modes: Auto, 8x/8x and 8x/4x/4x. I selected 8x/4x/4x and put only in the second slot these PCIe to 2x M.2 Adapter Card in: Dpofirs Adapterkarte mit 2 X 32 Gbit/s Erweiterungskarten, Dual M.2 NVMe SSD zu PCIE X8 M Key Festplattenkonverter Leser Erweiterungskarte, Unterstützt Full Speed NVME SSD/M.2 PCIE(ph45) In these PCIe Adapter I would connect 2 of these JMB585 SATA Controller cards with 5x Sata ports each. Unraid itself detects all fine. Both JMB585 are shown correctly and the connected HDD's will also shown and accesable: (in this picture the HDD's were not shown because they are bounded to VFIO for passing through to a VM) The problem I have is when I passthrough both devices to one and the same vm I get the error: internal error: Unknown PCI header type '127' for device '0000:02:00.0' I also tried to play with these arguments in the syslinux config at the boot: vfio-pci.ids=197b:0585 or xen-pciback.hide=(02:00.0)(03:00.0) which I had from this thread because of the same Vendor ID of the both JMB585 But still the same Error 127... When I go with the mouse in the system devices over the first JMB585 this pops up (maybe one other an other person know what to get out of this information): Inside the VM and its template I passthrough the devices like this: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> </hostdev> <memballoon model='none'/> </devices> </domain> I think here is all fine and like the way it should be done... //EDIT: The freakiest part of the things: Here it should be added that it did not work all the time, and I just left the server on for 1 hour or so. I tried it again and it starts the VM... So slowly I despair of the sense here. Could it be that after an unraid, i.e. host reboot, it takes a while until it stops addressing the PCIe devices and they virtually "go into standby" so that they lose the "already booted status"? I shut down the VM afterwards and could restart it immediately without any problems... buuuut when I did Unraid itself restarted and I get again error 127. After many try I can not reproduce this described scenario... At this point I have to give up and will be happy if you guys can help me! Thanks a lot for your time and reading my problems!!!

Sonst noch irgendwelche Tricks auf Lager? Habe die Kiste nun 2 mal neugestartet und einmal 30min und einmal 60min gewartet. Ohne Erfolg. Somit war das irgend so ein Zufallsding, das es vorhin einmal funktioniert hat. Umgesteckt wurde nichts. Ebensowenig an den Bios Settings oder ACS Override Settings was geändert. //EDIT: Die beiden JMB585 haben ja die selbe Verdorr ID. Wenn ich mit der Maus über den ersten gehe erscheint folgende Info. Vielleicht hilft es ja: Bei den USB Geräten, sofern diese die selbe Verdor ID haben gibt es ja auch Probleme und da wird mittels folgendem Workaround getrickst. Dies lässt sich aber auf PCIe Devices nicht ableiten nach meinem Verständnis: VM USB PASSTHROUGH MULTIPLE DEVICES WITH THE SAME VENDOR/PRODUCT

Ehm Nein wie mach ich den das? Ich dachte unter System Diveces sehe ich nur die BUS IDs der einzelnen PCI Devices, dort sehe ich ja keine Kennung der Slots oder?

Hi @all und Hi @mgutt, aus dem Thread mit den 20 bzw. 24 Sata Ports Erweiterungskarten hast du ja gelesen, dass ich ein PCIe zu M.2 Adapter und darin 2 M.2 zu 5x Sata Controller mit jeweils einem JMB585 Chip zum testen da habe. Die Windows VM läuft weiterhin wie oben beschrieben mit dem angepassten Bios ROM ohne Probleme. Parallel beides zum laufen bekommen habe ich nicht. Somit habe ich aktuell alle PCIe Devices entfernt und nur die neue Adapterkarte mit den beiden JMB585 Controller im zweiten (der beiden direkt an die CPU angebundenen Ports) verbaut und diesen in den Settings auf x8/x4/x4 eingestellt. Damit kann der zweite Port beide Controller erkennen und zeigt in Unraid auch brav beide an - ebenso die daran angeschlossenen HDD's. Beide Controller habe ich an VFIO gebunden und ebenfalls in der Syslinux Config geblacklistet. Ebenso habe ich diese an die VM angehangen. <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> </hostdev> <memballoon model='none'/> </devices> </domain> Es kommt beim Start nun immer die Fehlermeldung wie davor schon auch bei der Win VM mit GPU und fehlender ROM. Oder wie du sagst der nichts aussagende Fehler 127: internal error: Unknown PCI header type '127' for device '0000:02:00.0' Du sprichst oben von: Für solche Fehle gibt es verschiedene Lösungsansätze. Hast du noch was in der Trickkiste auf Lager? Bei einem JMB585 kann ich ja keine modifizierte Rom einhängen wie bei der GPU... //EDIT: Hier sei ergänzt, dass es die ganze Zeit nicht geklappt hat, und ich den Server eben angelassen habe für 1 Stunde etwa. Ich habe es nochmal probiert und siehe da er startet auf einmal die VM... So langsam verzweifle ich hier an der Sinnhaftigkeit. Kann es sein, dass er nach einem Unraid also Host reboot eine Zeit brauch bis er die PCIe Devices nicht mehr anspricht und diese quasi "in den Standby fahren" damit sie den von dir o.g. "bereits Hochgefahren Status" verlieren? Ich habe die VM danach herunter gefahren und konnte sie sofort ohne Probleme wieder neu starten... Unraid selbst neugestartet und erneut Fehler 127. Ich lasse ihn wieder 30 min stehen und versuche es anschließend erneut.

Danke habe ich schon bestellt kommen morgen an. Werde heute dennoch mal mit 3 single Platten die noch frei sind mal mit dem LSI 9211-8i ein raid5 in der vm aufbauen und anschließend gehen die beiden JMB585 tauschen und die Platten verstreut über beide Controller durchreichen. Hier gilt es dann zwei Hürden zu schlagen. 1. den Fehler ‘127‘ zu vermeiden beim durchreichen der Controller 2. hoffen das der Synology VM für das RAID5 die Laufwerks Reihenfolge und Aufteilung egal sind. Das habe ich vielleicht missverständlich ausgedrückt. Als ich meinen Server vor drei Jahren aufbaute hatte, waren die Backplanes noch nicht vorhanden. Somit hatte ich den LSI 9211-8i direkt an den sata Platten mit den o.g. Kabeln im Einsatz. Als dann später die Backplanes kamen, mussten SFF zu SFF Kabel her. Jetzt wo ich das hier gerade schreibe fällt mir ein, das ich mir damals schon die Frage der Reihenfolge in den Backplanes gestellt hatte. Damals aber via Try and Error einfach ausprobiert und es hat geklappt. Also entweder hatte ich Glück und habe in beiden Backplanes die Reihenfolge korrekt erwischt oder dem raid ist es egal in welcher Reihenfolge die Platten kommen.

Also anscheinend hast du Recht @mgutt, die PCIe zu M.2 Platine läuft. Meine NVMe wird darin sauber erkannt. Die beiden M.2 zu 5x Sata sind anscheinend defekt. Ich habe Sie auf die beiden Onbard M.2 Steckplatze meines z590 Board gesteckt. UNraid erkennt diese zwar als JMB585 Device an, zeigt aber keine einzige angeschlossene Platte. Oder aber es liegt an den verwendeten 4xSATA zu SFF-8087 Kabeln welche an den Raidsonic HDD Käfigen angeschlossen sind. Versuche gleich nochmal direkt Platten via Sata zu verbinden. Also ich habe die Fehlerquelle lokalisieren können. Sowohl die PCIe zu M.2 Adapterkarte läuft sauber, als auch die M.2 zu 5x Sata JMB585 Karten (hier sowohl auf der Adapterkarte als auch auf dem Mainboard direkt) Meine Fehlerquelle sind die SFF-8087 Kabel. Hier habe ich folgende in Verwendung: YIWENTEC Mini SAS 36p SFF-8087 zu 4 SATA Target Festplatte Connector Daten kabel 0.75m Diese sind an Rackmaxx bzw. Raidsonic RM324 Backplanes angeschlossen, welche eben einen MiniSAS Anschluss haben. Es scheint so, dass die Kabel nur in eine Richtung funktionieren. "SFF-8087 zu 4 SATA Target" Heißt es ja in der Beschreibung. Das habe ich auch 100% überprüft und auch direkt versucht vom Mainboard an die SAS HDD Käfige zu gehen, auch hier werden keine Platten erkannt. Jetzt heißt es Hausaufgaben machen und hoffen, dass es "4x Sata (Host) zu SFF-8087 (Target)" Kabel gibt. //EDIT: Bzw. such ich morgen mal das Handbuch der RM324 raus und hoffe man kann mit den vielen Pins auf der Rückseite irgendwelche configs einstellen. Denke aber das waren alles nur PINS für die Lüftersteuerung, Pipser usw //EDIT 2: Habe eben bei Amazon tatsächlich die benötigten Kabel finden können. Hätte nicht gedacht das es da einen Unterschied machen würde. Samstag geht es dann an das weitere Testen. Hoffe bekomme dann nicht wieder den Fehler: internal error: Unknown PCI header type '127' for device '0000:02:00.0' beim durchreichen an die VM. CableCreation [umgekehrtes Kabel Mini SAS 36 Pin (SFF-8087) Stecker auf 4 SATA 7-polige Buchse, Mini SAS (Target) auf 4 SATA (Host) Kabel, 0,5 m

Das bezieht sich denke ich nicht auf alle drei mechanischen Ports die am Board vorhanden sind. Die ersten beiden Ports sind an die CPU gebunden und auch nur für diese beiden lassen sich diese Bifrucation Settings auch einstellen. Jedenfalls verstehe ich das so, korrigiert mich wenn ich mich irre. Der dritte mechanische Port am Board hängt am Chipsatz und ist immer x4 fach angebunden.

Soweit bin ich erst gar nicht gekommen. Wie schon geschrieben, unterstützt mein Board (Gigabyte Z590 Aorus Master) in den beiden ersten mechanischen x16 Slots, die auch direkt an die CPU gebunden sind mit 16 Lanes folgende Modi: x16, x8/x8 und x8/x4+x4: Nur wenn ich letztere Einstellung setze wird in Unraid unter den PCI Devices auch tatsächlich beide M.2 to 5x Sata Adapter JMB585 erkannt... Was jedoch komisch ist, dass die daran angesteckten Platten nicht erkannt werden, sowohl in Unraid nicht, in einer Baremetal Windows Installation nicht, und die beiden Karten lassen sich auch keiner VM durchreichen. Es kommt wieder der Fehler: internal error: Unknown PCI header type '127' for device '0000:02:00.0' Wenn man sich die PCIe Karte selbst anschaut leuchtet diese mit zwei grünen LED's für die beiden NVMe M.2 Steckplätze mit grüner LED, somit sollte da alles tutti sein. Werden ja auch beide in Unraid grundsätzlich erkannt. Betrachtet man aber die LED's auf den JMB585 Adaptern sind diese aus und müssten eigentlich leuchten. Irgendwo ist da der Wurm... Habe da jetzt meine 8 Platten dran welche aus 2 Festplatten Käfigen kommen. Diese wurden mit einem SFF-8087 zu 4x Sata Kabel angeschlossen. Vielleicht ist da der Wurm teste das morgen mal mit Normelen Sata Kabeln. Hatte diese aber damals als ich noch keinen LSI 9211-8i im Einsatz hatte in Verwendung und direkt am Mainboard angeschlossen. Das lief! Hatte es sowohl in UEFI als auch Lagency Boot versucht. Mit Passthrough und Blacklisting in der Syslinux Configuration beim Boot. CSM war jedesmal an. Berichte morgen weiter. Für heut ist Feierabend.

Hallo @all, sorry für für die verspätete Rückmeldung. Corona hat bei uns voll reingekickt! @mgutt da zeigt sich wieder mal, dass ich nur gesundes Halbwissen auf dem Thema Unraid besitze. Ich habe alles so gemacht wie du es gesagt hast. Bios reset habe ich jedoch nicht. Lediglich CSM on belassen und alles auf Legacy umgeswitched. Gebootet vom Stick dann aber in UEFI. Es war echt notwendig erst nur die GPU einzubauen und diese der Windows VM vollständig fertig zu konfigurieren. Sprich auch der Schritt mit der angepassten BIOS Rom. Mir war auch nicht klar, dass man "Fehlerbehaftete VM's" löschen muss und mit einer sauberen Config starten sollte. Danke auch für diesen Tipp! Zusätzlich habe ich aber noch die Mellanox Karte in der Syslinux Configuration ebenfalls geblacklistet und via VFIO gebunden. Ergebnis ist, dass bei de VM's starten und alles läuft. Ich muss nur beim Starten der VM's aufpassen, beide zeitgleich geht nicht. Erst muss eine sauber durchbooten und erreichbar sein, dann geht auch die zweite an. Performance ist ebenfalls gut. Der LSI 9211-8i hängt mit 8x WD Red 6TB Platten (Lese Geschwindigkeit pro Platte etwa 160-180MB/s laut Hersteller) in einem RAID 5 Verbund ohne SSD Cache. In der WinVM (Unraid Server ebenfalls mit 10 GBe angebunden) erhalte ich eine Lese und Schreibgeschwindigkeit von 700-850 MB/s. Ich hatte anfangs rein theoretisch gedacht und gehofft, dass man bei 8 Platten (eine geht für die Parität drauf) somit 7x 160MB/s = 1120 MB/s realisieren könnte. Habe im Netz dann aber rausgelesen, dass meine erzielten Werte der tatsächlichen Realität entsprechen und sehr stark vom I/O abhängen wieviele und wie große Daten man transferiert. Ich habe hier noch 2 Sata SSD's (Read Write Speed 500MB) und eine NVMe PCIe 2.0 mit 1500MB's Read und 1000MB's Write Speed. Bin am überlegen mit dem SSD Cache zu experimentieren. Wäre dann aber die eierlegende Wohlmichsau. Benötigen tue ich das eigentlich nicht, da das NAS RAID5 Pool eher als Datengrab benutzt wird. Das einzige Szenario wo man eventuell was reißen würde, wäre Emby. Ich denke bei Scans der META Daten kämme die dann noch zum Einsatz. Ausprobieren will es aber auf jeden Fall. An dieser Stelle möchte ich mich nochmal bei allen hier beteiligten Personen ganz herzlich bedanken! Ohne euch hätte ich das nicht geschafft! Großes Lob an euch alle! @mgutt vielleicht noch für mich als Laien um das Problem bis zum Ende zu verstehen. Wenn ich das richtig interpretiere, dann war das allerlei Wundermittel die fehlende ROM in der GPU, was du ja auch schon ganz zu beginn dieses Threads geschrieben hast. Ich habe in der Vergangenheit unter dem alten System definitiv diese GPU schon ohne ROM durchgereicht und konnte die VM ohne Probleme nutzen. Was passiert hier somit im Hintergrund? Wenn du Lust und Zeit hast - kläre mich bitte auf!

@DataCollector Du verstehst mich nicht weil du dich vom typischen Unraid aufbau nicht lösen magst. Ich nutze das Unraid Array nicht. Meine 8 Sata HDD's hängen am LSI 9211-8i und sind mittels VFIO passthrough an eine Synology VM. unraid kann diese Platten gar nicht sehen. In der VM ist ein Software RAID5 aufgebaut.

Hallo @DataCollector, ja Unraid ist bei mir nur als Hypervisor im Einsatz. Meine Festplatten habe ich in einer Synology VM welche sich Xpenology nennt und dort reiche ich den LSI 9211-8i im IT mode durch an dem die 8 Sata Platten hängen. Der Plan ist es den HBA gegen die beiden JMB585 zu tauschen um die o.g. Vorteile zu bekommen. Frage ist nur ob dann ein RAID rebuild notwendig sein wird. Try and error würde ich sagen. Habe mir eben das Teil bestellt. Das Unraid Array nutze ich gar nicht. In einem SSD Pool laufen nur die ganzen Docker um VM's

Hallo @all, interessantes Thema hier. Ich bin auch am überlegen meinen Dell 310 HBA à la LSI 9211-8i gegen so eine PCIe x8 to 2 M.2 NVME Karten in verbindung mit zwei M.2 to 5 Port Sata und JMB585 Chip zu tauschen. Ich erhoffe mir dadurch einen geringen Stromverbrauch, die Möglichkeit meine Festplatten fehlerfrei unter Xpenology schlafen legen zu können und zwei zusätzliche Sata Ports. Mein z590 Chipsatz kann zwei mechanische x16 Ports auf 8x / 4x+4x aufteilen, sollte somit klappen. Performance technisch denke ich sollte es keinen spürbahren Unterschied machen, oder? Die Frage die ich mir stelle ist: Muss ich die 8 HDD's die durchgereicht werden bei einem Wechsel neu zu einem RAID5 zusammenbauen? Denke ja nicht, da der LSI im IT mode die Platten ja auch nur wie ein SATA Host Controller die Platten durchreicht, oder? An diese Kombo habe ich gedacht: PCI-E X8 Split Card to SATA 10-Port Adapter Card JMB585 Chip Supports PCI-E3.0 4.0

Du sagst du hast das z490 mit dem 9900k. hast du den auch alle drei Slots belegt mit ähnlicher Konfiguration wie ich? habe jetzt wild mit den slots rumprobiert... sobald was in slot zwei drin ist, egal was kommt der Fehler 127 als ob die beiden pci4.0 Slot 1/2 nicht in der Lage sind sich die 16 lanes zu teilen. Lasse ich Slot 2 frei läuft alles normal. die gpu in Slot 3 geht nicht da der Kühler zu groß ist... leider. Aktuell habe ich die mellanox im Slot 3 und die wird jedesmal ohne Probleme erkannt. In Slot 2 ist der HBA und jetzt löst dieser error 127 aus.

Das ist so nicht ganz richtig - ich hatte ja geschrieben: "Trotzdem: internal error: Unknown PCI header type '127' for device – egal ob vfio gebindet sind oder nicht" Hierzu habe ich noch eine Frage: (Nicht wundern habe hier die Reihenfolge zwischen GPU und NIC getauscht) CSM aktiv Im Bios alles einstellbare auf Legacy eingestellt und auch Legacy gebootet PCIe ACS Override auf Downstream gestellt. Alle drei PCI Devices (GPU, NIC und HBA) via VFIO gebindet und den entsprechenden VM's nach dem Reboot zugewiesen Nochmal rebootet Es ist keine VM eingeschaltet nur UNraid ist frisch gestartet und ich gehe in die System Devices => Warum hat nur der HBA einen grünen Punkt?? Genau deswegen wird sie wieder in dem Plugin angezeigt. Lass die Karte bitte an VFIO gebunden wenn du sie durchreichn willst und schmeiß das Plugin runter. Ja bin ich grundsätzlich mit einverstanden - aber warum zum Henker lässt sich dieser Zustand nicht reproduzieren?? For your info: Ich habe heute ein Telefonat mit ITS-Hähnlein wo ich die Mellanox Karte gekauft habe. Hier ist man der Meinung, dass es sich um ein Problem mit dem Consumer Board handeln muss und dieses sporadisch die x16 Anbindung mal richtig und mal falsch aufteilt. Möglicherweise ist das die Antwort darauf warum ich den oben beschriebenen Zustand nicht reproduzieren kann... By the way, ich kann leider dein Beitrag nicht finden habe aber mal gelesen wenn man Server PCI Karten auf einem Consumer Board betreiben will kann es ab und an sein, dass ein PIN abgedeckt werden muss... muss ich das was bei der Mellanox Karte berücksichtigen oder sind damit die markierten PINS gemeint: Normalerweise eben durch das Bindung der VFIO's und dann sind die PCI Devices ja in den VM's unten selektierter. Bei der Mellanox Karte hingegen habe ich das Problem, dass diese trotz des VFIO Bindings nicht auftaucht im VM Config Dialog, sodass ich diese klassisch manuell durchreiche. Anschließend wird diese dann auch im VM Config Dialog gelistet und ist "DE-selektierbar". Diese Einstellung würde ich wählen aber mit aktiviertem CSM und auch wirklich in den Legacy mode booten, mit dem erhältst du Erfahrungsgemäß die besten Ergebnisse, auch wenn die karte an VFIO gebunden ist. Einverstanden und war da auch ehr der Meinung, dass diese Einstellung die richtige sein muss! Folgende Config: => Mellanox Karte ist in Slot 1 verbaut und GPU wurde entfernt! Diese Einstellung betrifft ja nur die oberen beiden PCI Spots welche direkt an die CPU angebunden sind und hier ist 8x/8x die Einstellung die ich brauch In Legacy gebootet: VFIOs gebindet (es sei angemerkt der grüner Punkt ist weiterhin nur beim HBA) Mellanox Nie und HBA sind an die VM durchgereicht: Ergebnis: weiterhin Error 127 aber immerhin startet die WIN-VM was auch zu erwarten war, da keine GPU verbaut ist. //EDIT: habe mir eben mal die Manual von der Mellanox Karte angeschaut. Wenn ich es richtig verstehe handelt es sich physisch zwar um eine x8 Karte aber laut der angehängten Tabelle und meiner Interpretation kann ich diese wohl auch in ein x4 Port PCIe 3.0 stecken... Versteht ihr das auch so? Würde dann versuchen heute abend diese Gamechanger in den dritten Slot anstelle des HBA's zu stecken und über den Chipsatz anstelle die CPU anzubinden. Hier ein link zur Manual: MCX312A-XCBT Von dem Druchsatz her sollte rein rechnerisch auch ein x4 Anschluss reichen um zwei 10GB Nics zu versorgen (2000 MB/s würde hier ja reichen), nur hat die Karte ja nicht umsonst einen x8 PCI Anschluss, oder?

Hallo @mgutt @ich777 @RiDDiX, hatte es gestern nicht mehr geschafft alles durch zu probieren somit mein kleines Delay in der Bericht Erstattung. Spoiler: Sorry für die langen Beiträge - ich versuche alles möglichst chronologisch aufzubauen damit man alles nachvollziehen kann. Außerdem besteht das Problem weiterhin und ich denke mittlerweile, dass es was mit der Mellanox Connect-X3 MCX312A-XCBT Dual SFP+ Karte zusammenhängt, denn wenn diese nicht verbaut ist kann ich auch die GTX 1660 ohne Fehler an die WIN-VM durchreichen (bleibt zwar schwarz alles, denke liegt aber an der fehlenden ROM, von UNRAID kommt KEINE Fehlermeldung). Danke für diesen TIPP! Tatsächlich habe ich mit der M2 SSD aus der VM einen native Boot durchgeführt. Alles verbaut gelassen und Windows erkennt alles. GTX1660 ist verwendbar alle Onbard SATA Steckplatze und der LSI 9811 IT sowie die Mellanox Connect-X3 MCX312A-XCBT mit beiden Ports. Also denke ich habe ich hier wie du geschrieben hast keine Probleme mit der Hardware Konfiguration und alles ist so nutzbar! Schonmal gut an der Stelle! Hier die beiden Diagnostics vom Stick mit neuem Unraid 6.10rc2 und alter config. Hier habe ich weiterhin absolut nichts zum laufen bekommen. Plus das es eben die o.g. Fehlermeldungen im Dashboard gab. Ich habe hier extra mal in UEFI und mal in Lagency gebootet, falls das was ausmacht. unraid-server-diagnostics-20220222-1056 - neuer Stick mit alter config + all vifo UN-bount : UEFI Boot.zip unraid-server-diagnostics-20220222-1124 - neuer Stick mit alter config + all vifo UN-bount : Lagency Boot.zip =============================================================================================== Nachdem ich erfolgreiche Ergebnisse in Windows direkt mit der Hardware hatte, hatte ich Gewissheit, dass diese prinzipiell Laufen muss und wollte mich ein wenig weiter mit den BIOS Settings beschäftigen - vielleicht hat man hier was übersehen. Folgende für UNRAID interessante Settingsmöglichkeiten habe ich im BIOS finden können: Ist CSM deaktiviert so wird die Mellanox Connect-X3 MCX312A-XCBT Dual SFP+ im Bios angezeigt (siehe erstes Bild). Aktiviere ich CSM hingegen und dabei ist egal ob ich die Untereinstellmöglichkeit für "Storage Boot Control" und "Other PCI DEvices" entweder auf Legacy oder UEFI setze. Hatte es dann so belassen, dass Storage Boot Control auf Legacy und Other PCI Devices auf UEFI verbliebenen ist und die Mellanox Karte somit im BIOS nicht weiter sichtbar war (Unraid hingegen sieht diese weiterhin in den System Devices): Hat leider auch nichts gebracht außer das die BUS ID sich entsprechend der Einbau Situation angepasst hat. =============================================================================================== Spoiler: hier hatte ich kurzeitig ein Erfolgserlebnis... Alles jetzt nachfolgende habe ich mit 2 Boot Stick durchgespielt. Zu erst mit dem Stick und der Backup Config auf neuem Unraid 6.10rc2 und dann auf einem komplett neuen Stick mit Unraid 6.10rc2 inkl. Testlizenz. Außerdem wurden alle Szenarien einmal in UEFI und einmal Lagency Boot durchgeführt. Hier sei noch erwähnt, dass bei beiden Varianten auf gleiche Art und Weise entsprechend der gewählten Einstellung für die "PCIe ACS override" die IOMMU Groups generiert worden sind und ich diese somit nur einmal zeige: Als erstes mit Unraid 6.10rc2 alter config: Bei allen folgenden Varianten wurden folgende BIOS Settings verwendet: PCIe ACS Override -> Disabled => GTX1660 und Mellanox Connect-x3 in einer IOMMU Group Trotzdem: internal error: Unknown PCI header type '127' for device – egal ob vfio gebindet sind oder nicht PCIe ACS Override -> Downstream => GTX1660 mit Unterfunktionen in einer und Mellanox Connect-x3 in einer separaten IOMMU Group Trotzdem: internal error: Unknown PCI header type '127' for device – egal ob vfio gebindet sind oder nicht => In meinen Augen die beste Variante rein von der Aufteilung. PCIe ACS Override -> Multi-Function => GTX1660 und Mellanox Connect-x3 in einer IOMMU Group und zusätzlich noch die PCI Bridge … also bisher der schlechteste Modus Trotzdem: internal error: Unknown PCI header type '127' for device – egal ob vfio gebindet sind oder nicht (außerdem gleiches Ergebnis wie "Disabled") PCIe ACS Override -> Both => GTX1660 mit Unterfunktionen jeweils in einzelnen und Mellanox Connect-x3 in einer separaten IOMMU Group Trotzdem: internal error: Unknown PCI header type '127' for device – egal ob vfio gebindet sind oder nicht Für die Varianten 1-4 hatte ich immer auch zeitgleich ins Mellanox Plugin von @ich777 geschaut, ob die Karte da erkannt wird. In jedem Fall wurde sie nicht richtig erkannt, obwohl Sie in den System Devices in Unraid gelistet war: Da ich hier nicht weiterkam habe ich mit dem zweiten Stick und einer komplett unberührten UNRAID 6.10rc2 Version inkl Testlizenz mein Glück versucht. Als zweites mit Unraid 6.10rc2 fresh Install: Bei allen folgenden Varianten wurden folgende BIOS Settings verwendet: CSM Aktiviert – in UEFI gebootet – VIFO‘s unbount – Mellanox-X3 wird in PCI Devices angezeigt, UNRAID erkennt sie auch sowie auch das Mellanox Plugin von @ich777 PCIe ACS Override -> Disabled => GTX1660 und Mellanox Connect-x3 in einer IOMMU Group Erfolgserlebnis: Xpenology VM mit Mellanox Connect-X3 passtrhough funktioniert – auch nach Neustart des Systems selbst oder Neustart der VM. Aber auch nur sofern diese VM als erstes gestartet wird. Starte ich einmal die Win-VM und liefert den Fehler 127, dann geht auch die Xpenology VM nicht mehr Bei der Win-VM und der GTX 1660 trotzdem: internal error: Unknown PCI header type '127' for device – egal ob vfiogebindet sind oder nicht und egal ob die Xpenology VM läuft oder nicht Blöderweise kann ich ums Verrecken diesen Zustand nicht erneut reproduzieren und ich habe an diesem Zeit Stempel auch leider keine Diagnostics gesichert... Misst. Habe sogar extra einen dritten neuen Stick hierfür erstellt, leider Fehlanzeige, Slotwechsel und stundenlanges Demontieren bzw. Stromlosstellen hat auch nicht geholfen. Anhand des grünen Punkts ist zu erkennen, dass die VM mit passthrough läuft. siehe oben - exakt gleiches Verhalten siehe oben - exakt gleiches Verhalten siehe oben - exakt gleiches Verhalten Wenn ich mit dem neuen Stick die Variante 1-4 im Legency Boot durchteste erhalte ich ebenfalls die Ergebnisse wie mit der alten Config. Die Mellanox Karte wird einfach nicht erkannt inkl. Felher 127 beim durchreichen: Ich habe dann dennoch vom der Fresh Installation einmal die Diagnostics erstellt, aber leider an einem Zeitstempel wo das Passthrough nicht mehr geklappt hat der Mellanox Karte. tower-diagnostics-20220222-2050.zip So langsam bin ich mit meinem Latein am Ende. Keine Ahnung was ich falsch mache. Die Mellanox Karten werden ja als Refubrished Ware verkauft. Kann es sein das die einen weg hat? Das die mal richtig und vollständig erkannt wird von Unraid und mal nicht? An dieser Stelle möchte ich mich erneut bei euch Bedanken, dass ihr eure Zeit für meine Probleme opfert! Vielen Dank! //EDIT1: Hat man nicht irgendwie noch Möglichkeiten gehabt die PCI Karten komplett von UNRAID ignorieren zu lassen? Sprich noch ein weiterer Weg ohne das VFIO Binding? //EDIT2: BRAINSTORMING: MIt der Mellanox Connect-X3 habe ich dann insgesamt 3 10 GB Nic's im System. Leider kann man wohl die Mellanox Dual Port nur beide Ports zusammen an eine VM weiterreichen. Ich hatte mit dem Gedanken gespielt die Onbard 10GB Nic an die Xpenology VM druchzureichen und die Mellanox anstelle diese für Unraid zu verwenden, geht aber nicht weil Unraid die Onboard Nic immer verwenden will und diese entsprechend nicht anwählbar ist in den System Devices zwecks VFIO Binding. Offtopic: Auf der Xpenology VM läuft mein Datengrab im RAID 5 mit 8 Platten, wodurch ich eine 10GB Nic ausreizen könnte. Zugriff darauf ist aber nicht permament und eher durch Emby. Außerdem läuft dort die Kamera Software von Synology Surveilance Station mit 8 Cams die ebenfalls eigentlich nicht so viel Bandbreite benötigen. Wie würdet ihr es machen, eher die Dual SFP 10Gb Karte an Xpenology weiterleiten und dann im dynamischen Link Agg. Modus laufen lassen, oder ein Port für das RAID5 und ein Port für die Kamera Software belassen? Dann hätte Unraid nur einen 10Gb Onboard Port für alle anderen br0 VM's, Docker (NGINX, WIREGUARD, ADGUARD, EMBY mit 10 Usern) und Unraid eben selbst. Oder würdet ihr - sofern möglich - das ganze anderes rum fahren. Sprich der Xpenology VM nur die Onbard 10GB Nic zuweisen, was ihr eigentlich mehr als ausreicht und Unraid dann die Dual SFP+ karte im dyn. Link Agg. Modus? @all die eine Mellanox Connect-X3 MCX312A-XCBT Dual SFP+ Karte in Ihrem Unraid System verbaut haben. Die karte wird ja nur auf einer Bus Number angezeigt, hier ist es nicht möglich die Nic's aufzuteilen und seperaten VM's zuzuweisen - auch nicht mit einer neuen Firmware oder?

Mellanox Connect-X3 MCX312A-XCBT Uff Anfängerfehler meinerseits... denke ich. Der Ornder heißt auf dem Stick defintiv EFI da ja auch mit dem Unraid Stick creator UEFI angeklickt wurde. Wenn ich im BIOS CSM also legancy aktiviert hatte, dann habe ich möglicherweise trotzdem UEFI gebootet du hast recht. Der Stick wird ja zweimal gelistet. Einmal mit einem UEFI: Sandisc Cruizer und einmal nur Sandisc Cruizer. Letzterer wäre ja für den eigentlichen Legency Boot notwendig. Welchen er aber genommen hat, kann ich jetzt nicht sagen würde ich nochmal testen.... peinlich 🤦‍♂️ Kriegst du, aktuell bin ich noch bei der Arbeit.