GME Unraid Account

Hallo, das System Log File auf meinem Unraid Server (6.11.5 installiert) wird von folgender Meldung überflutet: program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO Wo könnte das herkommen ? Wie vorgehen, um die Ursache zu finden bzw. das Problem beseitigen ? RudiD

Und schon wieder ein neues Problem .... Ich hatte die übergangsweise eingebaute Quadro400Grafikkarte testweise auf eine der 3 WIN VM's durchgeschliffen, um zu sehen wie sich die Reaktion der Veeam-Backup-Software anfühlt, wenn man im Setup rumarbeitet oder auch nur den Setup-Assistenten aufruft bzw. zumacht. Ergebnis : Die Trägheit der VM hat sich auch mit durchgeschliffener GPU kaum verbessert. Anschließend habe ich alles wieder rückgängig gemacht (VFIO Bindung der Grafikkarte aufgehoben, rebootet und die Grafik im VM-Setup wieder auf VNC gesetzt). Die Grafikkarte habe ich zunächst im PCIe-Slot stecken lassen. Dann gab es nach dem Reboot die nächste böse Überraschung. Keine der 3 VM's lässt sich mehr durch VNC erreichen. Diese Meldung kommt mir jetzt entgegen: Rebooten hilft nicht. Kann mir jemandaus dieser Falle raushelfen ?

Ja, von gefühlter bare Metal Performance hab ich auch mal vor der Installation geträumt, leider kam es ganz anders. Korrekt, 1GB Cache zum Backup-Abspeichern von 30+x VM's ist alles andere als ausreichend. Ich habe den 1GB-Cache nur anfänglich in meiner Testphase benutzt, um dort nur ein paar wenige VM-Backups reinzuspeichern. Nur wenn sich alles auf dem Cache abspielt, komme ich ja zu wahren Ergebnissen, die mir sagen, welchen maximalen Performance-Level ich überhaupt erreichen kann. Nachdem ich dann aber einsehen musste, wie armseelig das alles ablief, habe ich entschieden, daß in keinen größeren Cache-nvme-Speicher Geld investiere, sondern nur die 3 WIN10-VM's zum Backupen meiner VMware-Maschinen im Cache laufen lasse. Die Backup-Dateien werden heute direkt am Cache vorbei auf das Array geschrieben.

Danke erstmal für die unerwartet schnelle Hilfestellung. Die 2 Onboard 1Gbit NICs habe ich im BIOS deaktiviert, da ich eine Dual-Port 10Gbit PCIe-Netzwerkkarte auf einem der beiden PCIe-Slots(x16) gesteckt habe. Auf dem 2.ten PCIex16-Slot hockt die Dual-10Gbit Netzwerkkarte. Nachdem ich im VM-Manager die Default-Einstellung mal auf Downstream geändert habe, fand endlich die Trennung der iommu's statt. ich konnte jetzt die Quadro400 Grafikkarte einer der VM's zuweisen. Soweit so gut ..... aber ... das Durchschleifen der Grafikkarte wollte ich jedoch aus einem ganz anderem Grund ausprobieren. Meine 3 aktiven WIN10 -VMs habe ich im Unraid System eingerichtet, um dort die Veeam-Backup-Programme zur Sicherung meiner 30+x virtuellen Windows Maschinen durchzuführen, die über 3 VMware-Hosts verteilt sind. Dazu wurde im ersten Schritt die gesamte Netzwerktechnik aller beteiligten Systeme auf 10GB-Technik umgerüstet. Der ürsprüngliche Charme dieser Konstruktion, auf dem Unraid -NAS gleich auch die Backup-Welt onboard zu haben, gepaart mit 10GBit-LAN (ähnlich wie moderne Synology-Systeme das heute auch anbieten), ging jedoch in allen Disziplinen bis heute in die Hose. Das Problem: Trotz Einsatz potenter Hardware im Unraid-System (ASUS-MB WS C246-PRO mit 128GB-RAM, 2 schnelle 1TB Samsung nvme-SSD's vom Typ 970-EVO als protected Cache auf denen die 3 WIN-VM's laufen) leiden diese 3 VM's für mich an unerklärlich schwacher Performance. Alle 3 VM's reagieren extrem träge, egal was man auf ihnen macht. Letzte Hoffnung bestand jetzt noch, daß das Durchschleifen der Grafikkarte noch was bringen könnte, aber es blieb nicht mehr als die Hoffnung. Der grafische Aufbau ist jetzt zwar etwas schneller, aber die VM's zeigen nach wie vor große Unlust etwas flott zu verarbeiten. Da bin ich von den VMware Maschinen ganz was anderes gewohnt. Auch meine zeitlich etwas zurückliegenenden Netzwerk-Performance-Tests bzw. der Ermittlung der Dateiübertragungsgeschwindigkeit bei reinen Kopiervorgängen zwischen dem Unraid-System und den Windows-VMs sowie auch von/zu physikalischen WIN-Servern fielen unfassbar schwach aus. Da kommt nicht viel mehr als die vorherige 1GBit Performance zustande. Um die Netzwerk-Performance zu puschen, habe ich seinerzeit intensiv mit mgutt kommuniziert aber letzlich die Löffel geworfen, nachdem nichts geholfen hat, auf einen akzeptablen Performance-Level zu kommen. Ich denke, daß jetzt die Rückkehr in die performante VMware-Welt ansteht, auch wenn ich dann wieder ein neues NAS von QNAP oder Synology dazukaufen muß, was ich eigentlich vermeiden wollte, da diese Hersteller stets nach ein paar Jahren den Betriebssystem-Support einstellen und man so gezwungen wird wieder eine neue Kiste anzuschaffen.

Das Motherboard im Unraid-System (ASUS WS C246-PRO) ist mit einer Xeon-6-Kern CPU (E-2226G CPU @ 3.40GHz) bestückt, welche über eine iGPU verfügt. In einen freien PCIe-Slot habe ich eine zusätzliche Grafikkarte Typ PNY Quadro 400 gesteckt, welche ich beabsichtige an die installierten 3 WIN10-PRO VM's durchzureichen. Im BIOS des Mainboards habe ich die iGPU als Main-GPU deklariert. Erwartet hatte ich nun, daß unter Tools > System Devices die PCIe-Grafik-Karte anwählbar ist, um diese an VFIO anzubinden. Überraschenderweise kommt mir aber folgende Sachlage entgegen: Anstelle der Quadro 400 Karte wird mir die iGPU (gelb markiert) zur Anbindung an VFIO angeboten. Wie ist damit umzugehen ? da ja immer gesagt wird: keinesfalls die iGPU an VM's durchreichen Was sollte ich hier nun tun ? Andere Grafikkarte kaufen und damit ausprobieren ? Vielleicht kann mir hier jemand helfen ? Gruß RudiD

Ich vermute, dass im UD Plugin noch der alte NTFS-3G verwendet wird. Brauchst du denn überhaupt NTFS? Wie wäre es mit BTRFS? @mgutt Ich habe folgende Absichten mit dem unRAID-Server: Es sollen 2 WIN10-VM's auf ntfs-formatierten UDev-Speichern im unRAID- System installiert werden. Auf diesen beiden VM's sollen Backup-Programme laufen, die ich seit Jahren, derzeit noch auf anderen physikalischen PC's im LAN laufen habe und unbedingt weiter benützen möchte. Die momentan noch existierende Dreicksbeziehung im Datenfluß bei den Backup-Prozessen (Quelle zum Backup-PC und von dort aus via iSCSI zum QNAP-NAS) möchte ich dahingehend optimieren, daß zukünftig der Backup-PC gleich im NAS integriert ist und damit die Wege zum finalen Speicherort von gesicherten Daten kürzestmöglich bzw. höchst performant bleibt. Wichtige Unternehmensdaten sollen dabei auf dem ausfallgeschützten Disk-Array landen, weniger wichtige Backup-Daten will ich dagegen nur auf UDev-Speichern sichern. Natürlich habe ich daran gedacht, die UDev-Backup-Speicher auch als BTRFS-formatierte Speicher zu betreiben, jedoch bleibt ja das Problem, daß bei beiden WIN10-VM's der Flaschenhals (schwache Write-Performance) bestehen bleibt, solange die ntfs-Anbindung dieser Backup-VM's Treiber-bedingt auf dem aktuell schwachen Niveau stehen bleibt. Bezgl. der ganzen Erneuerungsmaßnahmen in unserem Netzwerk (Übergang auf 10GB-Technik und höher performante Backup-Infrastruktur) stand ich beim Thema Auswahl der Backup-Hardware vor der Entscheidung entweder ein modernes SYNOLOGY-Racksystem anzuschaffen oder mich für eine Eigenbaulösung auf Basis von unRAID zu entscheiden. Synology bietet inzwischen eine extrem attraktive, integrierte Backup Lösung an, welche unbegrenzt viele VMware PCs, phaysikalische WIN-PCs und WIN-Server lizenzfrei in einer einzigen Applikation sichert. Das gibt so im Moment nirgendwo. Genau das will ich auch mit dem aufgebauten unRAID-Server erreichen. Falls ich das Ziel mit unRAID nicht erreichen sollte, kann ich immer noch die Synology Lösung anschaffen und einfach das gesamte neu angeschaffte SSD- und HD-Material umpflanzen. Die restliche neu angeschaffte Hardware (Rack + Mainboard + NT) kann ich für die Erneuerung von VMware Plattformen hernehmen, die demnächst auch ansteht. Die unRAID Lösung hat den Charm, daß die mir vertrauten Backup-Lösungen weitergenutzt werden können und daß ich hier wohl erstklassigen Support aus der Community bekomme. RudiD

Sorry, hab nicht dran gedacht das im letzten Post gleich mitzumelden ..... ja, Multichannel funktioniert. Ich habe jetzt auch mal das PowerShell-Kommando Get-SmbMultichannelConnection -IncludeNotSelected während der Dateiübertragung auf das UDev gestartet, und siehe da ..... da geht wohl was in die Hose. Die gelistete IP 192.168.1.5 ist der DomainController mit DHCP + DNS Service und ActiveDirectory. Hier dürfte doch das Performance Problem mit den UDev's seine Ursache haben oder sehe ich das falsch ? Vermutlich läuft da der Traffic über den DC. Ich weiß allerdings nicht wo ich hier ansetzen kann bzw. muß, um das Problem zu beheben. RudiD

Autsch! Bedauerlicherweise ist mir ein folgenschwerer Konfigurationsfehler beim Editieren der Datei smb-extra.conf unterlaufen. Fatalerweise hatte ich hier die IP-Adresse der Client-Gegenseite eingetragen und nicht die IP des unRAID-Servers (192.168.1.20). Jetzt steht da folgendes drin: Auszug aus dem DHCP-Server: Weiterhin folgende Updates: Es gibt definitiv beim unRAID Server und beim PC-Client nur eine LAN-Verbindung zum Switch. Nach der Fehlerkorrektur endlich weitaus höhere Datenraten, jedoch nur beim Schreiben auf das Disk-Array, nicht auf die ntfs-formatierten UDev-Speicher. Hier zunächst mal die Info zu den diversen Schreibzielen auf dem unRAID-Server: Der Freigabe mit der Bezeichnung 'Array-Ordner_01' ist das protected Cache zugewiesen (2x Samsung 970-EVO Plus à 1 TB) Hier nun der Schreibverlauf mit der 40GB Datei auf diesen Ordner: Zwar immer noch keine vollen 10GBit jedoch bereits schmerzerlösend. Auffällig: Der erste NVMe Speicher im Cache-Pool steigt temperaturseitig während der Schreibphase deutlich (+10°C) an, während der 2.te identische Speicher wenig ausschlägt. Der nächste Schreibvorgang auf den Ordner ohne Cache: Array-Ordner_02 Da passiert das, was auch zu erwarten war. Nachdem der ca 25GB große Cache im RAM überläuft, gehts runter auf das typische Niveau eines xfs Arrays. Bestätigt wird die Schlußphase durch die übereinstimmend ermittelte Rate beim unRAID Server, siehe Folgebild: Nun zu dem verbleibenden Wermutstropfen: Weiterhin schwache Write-Performance auf die ntfs- formatierten UDev-Speicher: Auf allen getesteten UDev-Speichern spielt sich das gleiche Szenario ab: Oben das Bild vom schnellsten Speicher, welcher als NVMe (Samsung 980-PRO 500GB) direkt auf einem Motherboard Slot sitzt. Gibt es eine Erklärung, warum die UDev-Speicher mit solch geringer Rate beschrieben werden ? Auch hier müssten doch die ersten 25GByte von den 40GByte mit High Speed in den RAM-Cache wandern, tut's aber nicht ? Gibt es Maßnahmen die Write-Performance auf UDev-Speicher zu erhöhen ? Was man allerdings im unRAID-Main-Dashboard während der Übertragung beobachten kann, das sind mehrfache Write-Burst's mit hoher Datenrate auf den NVMe Speicher. Dazwischen lange Pausen mit Null Aktivität.. RudiD

@mgutt: Danke für die Links zum Thema Performance Tuning. Ich habe das folgende Szenario versucht umzusetzen und bin dabei leider auf noch schlechtere Datenraten gestoßen. Folgend Infos zum Nachweis des Setups: a. am Unraid-Server eingerichtet: samba restart durchgeführt und sicherheitshalber auch noch gebootet. Welchen Einfluß die inkludierte smb-settings.conf auf das Geschehen haben könnte, weiß ich nicht. b. am Netzwerk-PC mit WIN10 PC nach Einrichten und reboot des unRAID-Servers ebenfalls gebootet. Das Kommando Get-SmbClientNetworkInterface wurde vor der Übertragung der 40GB Testdatei abgesetzt. Interface Index 8 zeigt völlig korrekte Rückantwort. Alles scheint OK zu sein. Das Kommando Get-SmbMultichannelConnection -IncludeNotSelected wurde während der Datenübertragung abgesetzt. Da kam aber nix zurück was positiv aussähe wie man oben sieht. Demnach funktioniert der Multichannel-Betrieb nicht, was man auch deutlich an der zustande gekommenden Datenrate sieht. So mies war das vorher nicht. Woran könnte das Versagen des Multichannel-Betriebs liegen ? RudiD PS: Ich bin inzwischen auf OS Version 6.11-rc2 übergewechselt, nachdem sich die Version 6.10.3 auch bei mir als generell instabil erwiesen hat. Bei mir traten Abstürze des OS aus heiterem Himmel auf. Habe etliche Beiträge im internationalen Bereich gefunden, die exakt das Verhalten mit 6.10.3 melden, wie es bei mir auch aufgetreten ist (Browser verliert die Verbindung zum unRAID-Server, schwarzer Screen am VGA-Ausgang des Mainboards, keine Reaktion auf den PowerButton, Tastatur und Maus).

Hallo und Danke erstmal für Eure Rückmeldungen. Nach den bereits absolvierten, zeitfressenden Tests die Schlinge endlich mal enger zu bekommen, mußte ich mir ein weiteres Test-Szenario einfallen lassen. Ich habe mich dann mal gefragt: Wie verhält sich eigentlich die Unraid-Server-Hardware, wenn man diese testweise mit einem Windows 10 bestückt. Wenn sich unter WIN10 die Netzwerk-Übertragung deutlich nach oben abhebt, bleibt ja nur eine Schlußfolgerung übrig: Das Unraid-OS wäre dann selbst die Fehlerquelle bzw. Problemursache bzw. irgendwelche Einstellungen darin, welche die Write-Performance dermaßen runtersetzt. Also habe ich WIN10 auf eine 500GB PCIe-NVMe (Samsung 980-PRO) installiert, welche direkt auf dem PCIe-Mainboard-Slot hockt. Und siehe da: Der Einspeicher-Verlauf der 40GB großen Datei vom Netzwerk-PC auf den Freigabeordner im Unraid-Server mit WIN Betriebssystem ( NVMe -Drive C:) sieht so aus: Es gibt zwar hier mehrfach Einbrüche bis auf ein 25% Niveau, was wahrscheinlich durch den Überlauf des WIN-seitigen Caches verursacht wird, jedoch wird der Netzwerk-Maximalwert von 10GBit/sec erreicht, was ich unter Unraid 6.10.3 im Write-Mode nie erreicht habe. Die Datenübertragung der 40GB Datei geht trotz der Einbrüche insgesamt flott über die Bühne. Beim Ausspeichern der 40GB-Datei vom Unraid-Server zum Netzwerk-PC sieht der Verlauf so aus: Darüberhinaus habe ich auch noch Datenspeicherungen auf weitere Speicherkarten vorgenommen. Der nachfolgende Verlauf zeigt das Beschreiben ein SATA-SSD Typ Samsung 840-500GB, welche am SATA-Port des Mainboards angestöpselt ist. Auch hier kann man it der Performance zufrieden sein. Der nachfolgende Verlauf zeigt das Beschreiben einer SATA-SSD Typ Samsung 870-EVO-2TB, welche am SATA-Port des Broadcom Mega-Raid PCIe-SATA-Adapters angestöpselt ist. Wie oben auch hier zufriedenstellende Performancewerte. Einen weiteren Schreib-Test habe ich mit einer Trial-Version von Unraid 6.11.rc2 mit absolut minimalistischem Setup durchgeführt. Ergebnis: alles war so träge wie bereits unter OS-Version 6.10.3 festgestellt (gleiche schwache Write-Performance auf allen Datenträgern) Was nun ? Macht es Sinn das entdeckte Performanceproblem an den Lime Tech Support zu berichten ? Oder was schlagt ihr vor, wie am besten vorzugehen ist ? Gruß RudiD

Ich habe mich kürzlich im Rahmen der geplanten Netzwerkumstellung auf 10GB-Technik entschieden auch ein neues NAS gleichzeitig neu zu installieren. Meine NAS-Entscheidung fiel diesmal pro Eigenbau-NAS auf Basis von UNRAID 6.10.3. Nach dem Eintreffen neu bestellter Lancom 10-Gigabit Switches (z.B. Layer 3 Modell XS-5110F) wurden auch die Komponenten zum Aufbau des Unraid-Servers angeschafft, bei dessen Inbetriebnahme ich mich gerade befinde. Das Unraid NAS möchte ich später vorwiegend für Backupzwecke von mehreren VMware Servern nutzen, die ich ebenfalls schon mit 10GB Netzwerkadaptern ausgestattet habe. Absoluter Schwerpunkt meiner momentanen Erprobungstätigkeiten liegt in der Performance-Beurteilung bei den Netzwerkaktivitäten oder einfacher gesagt: Was bringt mir der Wechsel vom 1GB-LAN zum 10GB-LAN bzw. welche Datenraten kann ich beim Beschreiben des HDD-Arrays bzw. auch beim Beschreiben von Unassigned Devices im Unraid-Server erreichen ? Nach erfolgtem Aufbau des Unraid-Servers gab es dann jedoch ziemlich herbe Ernüchterung beim Einspeichern von Daten auf die verschiedenen Shares im Array bzw. auf die SSD's im Unassigned Devices Bereich. Nachfolgend habe ich mal meine Testkonfiguration skizziert. Dem Disk-Array, bestehend aus zwei 20TB HDD's habe ich einen Raid1 Cache mit 2x 1TB onboard installierten NVMe's vorgespannt. Dazu noch einen weiteren 2TB großen unprotected Cache, welcher per PCIe-Adapter direkt auf dem PCIe-Slot/Sockel hockt. Ein zusätzlicher Broadcom PCIe-SATA-Controller mit 8 Ports erweitert die 6x S-ATA Ports des Motherboards. An diesem SATA-Controller sind 2,5" Samsung SSD's angeschlossen als auch eine 2,5" HD. Der links im Bild gezeichnete Desktop PC mit WIN10 ist ebenfalls mit einer hochwertigen PCIe-SSD-NVMe Speicherkarte (8TB) und einem 10GB Netzwerkadapter bestückt, von dem aus ich die 40GB große Testdatei auf den Unraid-Server los lasse bzw. auch empfange. Und nun die große Ernüchterung: Egal auf welchen Speicher ich im Unraid Server die 40GB Datei von außen schreibe, ich kam in keinem einzigen Fall über 250 MByte/sec. raus. Da der Unraid-Server mit 128GB RAM ausgestattet ist, bildet das Unraid-OS ja darin einen R/W-Cache mit 20% des RAM's , also gute 25GB. In diesen Cache werden ja die Daten zuerst zwischengespeichert bevor sie entweder an den Cache des Arrays weitergeleitet werden, wenn das Ziel das Disk-Array ist, bzw. beim Beschreiben eines UDev-Speichers vom RAM über den SATA-Controller dorthin weitergeleitet. Ich hatte erwartet, daß die Datenübertragung zum Unraid-Server für die ersten 20GB mit voller 10GBit Netzwerkgeschwindigkeit abläuft, um erst nach Überfüllung des RAM-Caches sichtbar einzubrechen. Wie ist das zu erklären ? Die nächste Verwunderung dann bei der Datenübertragung in die andere Richtung, also vom Unraid-Server zum außen liegenden Netzwerk-PC. Hier läuft alles wie erwartet. Liegt die 40GB Datei noch komplett im RAM-Cache von Unraid, haut dieser die 40GB Datei mit 1 GByte/sec. raus und das ohne auch nur einmal einzuknicken. Entleert man jedoch vor der Übertragung den Cache mit dem Befehl 'sync; echo 1 > /proc/sys/vm/drop_caches' muß sich Unraid die Daten von der Quelle holen und dann landet man bei 500 MByte/sec. Übertragungsrate und das auch hier ohne Einbrüche. Die 500MB/sec. entsprechen der maximalen Leserate der installierten SSD's. Das wäre dann ja an dieser Stelle mal alles in Butter. Hat jemand von Euch Profi's eine Idee, was den Datentransfer von außen hin zum RAM dermaßen heftig einbremst ? Ich habe für den Aufbau der 10GB-Technik mittlerweile massiv viel Geld ausgegeben, um den Netzwerk Traffic-Speed massiv anzuheben. Und dann bei 25% des Machbaren hängen zu bleiben ..... das kanns nicht sein. Bitte um Eure Hilfe RudiD

I have had exactly the same problems using a german localized WIN10-ISO-Pro (21H1 Build 19043 and later) installation disk, as described in Justin's post. After altering of the machine version from 6.2 to 5.1 in the xml, the configured 'virtio' network adapter appeared finally after booting the VM and did work properly. Hopefully all german Unraid users having installed Unraid 6.10.3 and want to setup WIN10 VM's (german localized ISO-version) and using VNC as graphic adapter will discover this post soon. It took me hours finding the above described workaround. In the next step I will try with a WIN11 installation and come back with a comment.