mgutt

Ich würde nach einer alten 32 Bit Version suchen, denn das Paket gibt es offiziell nur noch für 64 Bit und zb bei Proxmox steht extra im Wiki, dass man alte Versionen für alten Betriebsysteme verwenden soll: https://pve.proxmox.com/wiki/Windows_VirtIO_Drivers#Windows_OS_Support Die Frage ist wann das auf 64 Bit only umgestellt wurde.

Welche virtio ISO hast du überhaupt probiert (edit: sorry, sieht man ja im Screenshot)? Hier gibt es die neueste und alten Versionen: https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/

Ist das Win 7 denn 64 Bit?

Die Performance ist dann übrigens nicht so gut wie bei virtio. Falls die wichtig sein sollte, sollte man das mit dem Treiber doch mal checken oder man nimmt sich eine kleine SATA SSD und schleift die durch.

Any security concerns regarding log4j and your Minecraft Container?

/mnt/user/appdata zeigt die nur die Summe aus /mnt/cache/appdata und /mnt/diskX/appdata. Also nein, du kannst da nichts rauslöschen, denn es zeigt dir nur das an, was du auf dem Cache hast bzw wenn du in dem Pfad etwas löschst, löschst du es vom Cache. /mnt/user ist also kein realer Ordner, sondern nur eine "Verlinkung" auf beide Datenträger. Der Mover wiederum verschiebt Dateien zwischen /mnt/cache und /mnt/diskX. Wenn nun Appdata auf Prefer steht, bleiben die Dateien auf /mnt/cache. Steht er dagegen auf Yes, würde er sie nach /mnt/diskX verschieben und alle deine Container wären hinüber, da die jetzt nur noch /mnt/cache kennen. Aus dem Grund ist /mnt/user die Standardeinstellung, weil da die Position der Dateien egal ist und sich der Nutzer nicht mal eben alles kaputt konfigurieren kann. Am besten erstellst du einen neuen Share mit Yes, lädst ein paar Dateien hoch und schaust dann wo die Dateien vor und nach Mover-Aktivität liegen. Einfach damit du verstehst was da eigentlich passiert.

68GB nur für Docker Pakete? Welcher hat denn so große Installationsdateien?!

Falls du die erweiterte Ansicht bei den Containern aktiviert hast, dann deaktiviere die. Spart auch noch mal 1 bis 2% Last. Das Monitoring läuft nämlich 24/7, egal ob die WebUI offen ist oder nicht. Jo. Immer wenn eine SQL-Datenbank im Spiel ist, ist das ein Unterschied wie Tag und Nacht. Für viele kleine Zugriffe ist FUSE leider der letzte Schrott. Bei der Umstellung auf /mnt/cache muss man übrigens folgendes beachten: - geht der Cache kaputt, geht kein Container mehr. Wenn man dann zB appdata aus einem Backup auf dem Array wiederherstellt, wird auch nichts laufen bis man alle Container wieder auf /mnt/user zurückgestellt hat. - läuft der Cache voll, dann schmieren evtl die Container ab. Aus dem Grund stellt man am besten einen Free Min Space auf dem Cache Pool ein. Auf den Poolnamen klicken und dann da einen Wert eintragen. Ich empfehle mind 10GB. Ich habe sogar 100GB eingestellt, da ich manchmal bis zu drei Blu-Rays parallel rippe und es zu einem Fehler kommt, wenn die parallel den Cache voll schreiben. So ist mir der Cache noch nie vollgelaufen bzw aus Sicht der Shares ist er dann voll und weitere Uploads gehen direkt ins Array und die Container haben noch genug Platz und laufen fehlerfrei weiter. Ich habe gerade mal aus Interesse die Belegung ermittelt. Also /docker zieht keine 6GB und normal ist das Image ja alleine 20GB groß: du -hs /mnt/cache/* 299G /mnt/cache/Movie 283G /mnt/cache/Music 159G /mnt/cache/appdata 5.6G /mnt/cache/docker 32G /mnt/cache/domains 1.1G /mnt/cache/system 492G /mnt/cache/web

Das heißt? Läuft die VM und dir fehlen jetzt die Virtio Treiber? Ist die ISO als DVD-Laufwerk gemountet? Wenn ja, hast du die Setup Dateien im Root des Laufwerks ausgeführt? Von Hand muss man da normalerweise nichts installieren. Die beiden Setups erledigen das automatisch.

Türlich. Gibt ja auch die Ordner-Installation und nicht nur Image. Dadurch fällt der Overhead vom Image weg und Docker belegt auch viel weniger Speicherplatz. Dann muss man aber kurz über Apps > Previous Apps die Container wiederherstellen, da er dann die Pakete bei runterladen muss.

Check vorher noch über Shares > appdata Ordner Symbol > LOCATION, dass wirklich alle Containerdaten auf dem Cache liegen. Ansonsten müssen die erst mit dem Mover verschoben werden.

Wie gesagt. Wenn Xeon, dann am besten Workstation (also mit iGPU). Man hat zwar weniger Lanes, aber das Problem mit der GPU für unRAID ist schon mal weg. Außerdem sind die effizienter. Falls das überhaupt ein Thema für dich ist. Ich habe den Vorvorgänger vom W-12xx. Den E-21xxG. Es gibt auch noch den E-22xxG. Alle optimal für unRAID.

Ok. Dann ist ja fein.

Die 9p virtio Geschichte ist allgemein lahm. Das ist aber bekannt und niemand nutzt das. Wenn dann nur SMB oder NFS. Auch wenn man SSDs hat ist /mnt/user langsamer als /mnt/cache. /mnt/user Pfade laufen durch den FUSE Prozess, während /mnt/diskX bzw /mnt/cache Pfade direkt auf den Datenträger zugreifen. Deswegen sehen meine Docker Einstellungen so aus: Und alle meine Container greifen direkt auf /mnt/cache zu.

Schau in den Ordner ob was drin ist: ls /mnt/cache Wenn nein, dann löschen: rmdir /mnt/cache Wenn der weg ist, sind die Cache Einstellungen der Shares egal. Die greifen dann nicht mehr. Alles was in /mnt/cache/appdata war, kopierst du nun nach /mnt/disk1/appdata Das war es dann. Danach sind die Daten über /mnt/user/appdata für die Container wieder verfügbar.

Weil du keinen Cache-Pool hast und solange du keinen Cache-Pool hast darf der Pfad /mnt/cache nicht existieren. Also nicht mal der Ordner darf da sein. Erstmal hast du nur den Inhalt von cache verschoben und nicht den Ordner selbst gelöscht. Dadurch dürfen alle Shares wo der Cache noch aktiviert ist, weiterhin da rein schreiben. Der Ordner muss weg. Hast du einen oder mehrere Shares beim Cache auf "Only" gestellt? Das wäre jetzt problematisch, da du ja eigentlich gar keinen Cache hast.

Wenn dieses Programm sehr viele kleine Dateien und/oder Datenbanken liest/schreibt, dann kann es sein, dass SMB dein Problem ist. Das löst man, in dem man Disk Shares verwendet und/oder SMB Multichannel+RSS aktiviert. SMB Multichannel ist in Windows meine ich standardmäßig aktiv, weshalb das gut sein, dass das deswegen schneller geht. Hier mal den Abschnitt mit RSS lesen und durcharbeiten: https://forums.unraid.net/topic/97165-smb-performance-tuning/ Und ein Beispiel, wo SMB Multichannel und RSS aktiviert wurde und ein neuer Share names "ProgrammeAufCachePool" hinzugefügt wurde, der direkt auf "/mnt/cache/Programme" zugreift: In Unraid sind die Disk Pfade "/mnt/diskX" bzw "/mnt/<poolname>" CPU-schonender als "/mnt/user", da dort noch eine zusätzliche Schicht namens FUSE hinter steckt.

Paketverluste dürfen niemals auftreten und dass daraus Folgeprobleme entstehen können, ist nur logisch. Jedes mal wenn ein Paket verloren geht, wird es neu gesendet. Also wenn jedes zweite Datenpaket verloren geht, hat man automatisch 50% Geschwindigkeitseinbruch und bei höherem Verlust natürlich noch mehr und RDP ist ein Streaming-Protokoll. Kann gut sein, dass das auf zu viele Verluste allergisch reagiert. Poste mal deine Netzwerk-Einstellungen, die XML von der VM und die IP-Einstellungen der Fritz!Box, also wo man die Mac-Adresse dieses Clients sieht. Prüfe auch mal ob die Mac-Adresse übereinstimmt, auch wenn ich da weniger das Problem sehe. Außerdem bitte mal deine Syslogs bereitstellen (Diagnostics), damit wir evtl allgemeine Fehler in deinem Netzwerk finden.

Ich mache doch jetzt nichts anders oder wie? Ok, ich hab noch nicht den Papierkorb gelöscht. Aber das kann ich ja noch machen.

Jo, ich habe nur den alten Pfad gelöscht, die neuen hinzugefügt und abgespeichert. Sonst nichts gemacht und der indexiert dann ja direkt automatisch neu. Vor dem Indexieren: nach dem Indexieren: Also der jeweilige Gesehen-Status ist erhalten geblieben.

Du hast recht. Wenn der RAM einmal komplett überschrieben wurde, kann es sein, dass alle Platten hochfahren. Hatte ich gerade beim Abspielen von Musik und das obwohl dieser Share per "Prefer" dauerhaft auf dem Cache liegt. Beim Plex Container hatte ich /mnt/user/Music hinterlegt. Hätte ich jetzt nicht gedacht, dass der dann alle Disks dafür hochfährt. Also sorry, du hattest recht. Wird Zeit alles auf Disk Shares umzustellen ^^ EDIT: Der erste Schritt ist getan:

Was heißt "Grenzen"? Weil ein 4-Kerner mit der Leistung, muss das doch locker wegstecken können: https://www.cpubenchmark.net/cpu.php?cpu=Intel+Xeon+E3-1280+V2+%40+3.60GHz&id=1779 Oder allgemein wegen der VMs? Ich mein klar. Da wären mehr Kerne natürlich sinnig. Dir hätte ich jetzt den W-1270P oder W-1290P empfohlen. Unraid gönnt sich dann die iGPU und die kann dann gleichzeitig für Plex genutzt werden, so dass deine zweite GPU auch gleich wegfallen würde.

Dann darfst du in der VM aber keine feste IP vergeben, sondern musst DHCP aktiv lassen. Von wo nach wo hast du gepingt? Hast du mal von deinem Client nur Richtung Fritz!Box gepingt? Hast du mal vom Client Richtung Unraid Server gepingt? Und auch mal vom Unraid Server Richtung Client? Ich tippe darauf, dass die Netzwerkverbindung des Servers ein grundsätzliches Problem hat und nicht nur die virtuelle Verbindung der VM.

Nur als Info. Sobald der Ordner /mnt/cache existiert und die Shares beim Cache auf Yes oder Prefer stehen, schreiben diese automatisch in den Ordner. Komisch ist allerdings, dass der Ordner erstellt wurde. @ich777 meinte mal, dass wenn ein Container auf /mnt/cache eingestellt ist, dass der Pfad dann automatisch in /mnt/user geändert wird, wenn man keinen Cache hat. Prüf mal bitte alle Container. Auch die versteckten Optionen. Irgendeiner hat als Pfad /mnt/cache eingestellt.

Du hast keine Cache SSD, korrekt? Dann hast du mal einen Docker gehabt, der den /mnt/cache erstellt hat. Vermute ich. Wenn du keinen Cache hast, dann kannst du den Ordner wie folgt löschen: rm -r /mnt/cache Oder sind da wichtige Daten von Docker drin? Dann auf deine Disk verschieben: mv -v /mnt/cache/* /mnt/disk1/ rmdir /mnt/cache