alturismo

ja, sofern beides lizensierte Unraids sind kannst du ganz bequem Backups anderer Installationen nutzen, dazu folgendes von Maschine a/ nach b/
 
Docker, Dienst auf Maschine b/ aus.
1/ /flash/config/plugins/dockerMan/templates-user << die Start Parameter deiner Dockers
2/ /mnt/user/appdata/docker1234 << die persistent Daten der Dockers (der individuellen Settings, Stände, ...)
jetzt, wenn Docker Image genutzt wird
3/ /mnt/user/system/docker/ << da liegt das Image, dann wären die Dockers auch direkt startbereit nach Service Start Maschine b/
jetzt, wenn das Docker Verzeichnis (directory) genutzt wird ... würde theoretisch auch gehen den Ordner zu kopieren, dauert aber ewig ... da mio von Dateien
3/ Docker Service Start, Docker Tab, unten add Container, oben mittig dropdown (user templates), die Docker laden und einfach Apply klicken, Docker werden schnell mit den passenden Start Parametern aus 1/ und den vorhandenen appdata aus 2/ gestartet, alles ist wie auf maschine a/
 
VM, Dienst auf Maschine b/ aus.
1/ /mnt/user/system/libvirt/ << wie oben beschrieben, die base VM Infos ...
2/ /mnt/user/domains/ << die effektiven VM disks
3/ VM Dienst an .. vorhandene VM's sollten da und startbereit sein ... Achtung, bei passthrough (devices, USB, ...) ggf. anpassen ... fertig.

also, das "graue" bedeutet dass die Karte "in use" ist vom OS (Unraid), daher kannst du die nicht "lösen" ...
 
es gibt Wege diese zu lösen, dann wäre jedoch die Karte auch nicht mehr für Dockers und co zu nutzen (Transcoding ...) falls dies auch gemacht werden sollte.
 
und letztendlich ... wüsste ich nicht dass dies noch jemand ans Laufen bekommen hat, die iGPU vollwertig in einer VM zu nutzen ... wenn dann sr iov (Intel) und vgpu's ... ja, das geht problemlos, aber auch bei Intel die komplette iGPU an die VM und beispielsweise nen Monitor dran ist "Geschichte" ...
 
da AMD jetzt auch noch kritisch ist was passthrough angeht (leider) ... glaube ich nicht wirklich dran das selbst wenn du die "gelöst" bekommst und dann in die VM gibst damit glücklich wirst
 
wenn wir uns jetzt noch deine iommu Gruppen anschauen ... machen wir es kurz, lass es  wenn du unbedingt willst ...
 
vorweg, warum hast du die 2 Geräte bereits vfio bind gesetzt ? was sollte das ? oder für was soll das gut sein außer Probleme ...
 

 
wenn du hierzu keine Antwort hast (nur mal getestet), revidier das !!!
 
1/ aktiviere mal PCIE override, settings, VM Manager, advanced view ...
 

 
das "Warning" steht nicht zum Spaß dabei ... aber gut, erster Neustart danach und die iommu begutachten, ggf. alle 3 Varianten ... Downstream, Multi, Both ...
 
Ziel, die iGPU und das dazugehöroge Audio Device in eine eigene Gruppe zu bekommen !!!
 
wenn das erledigt ist ... gibt es Start Parameter Unraid ohne Grafik (headless) ans Laufen zu bekommen
google, lesen !!!
 
und / oder die iGPU auch manuell per vfio syslinux Eintrag zu lösen, ebenso google, lesen
 
oder natürlich die Suchmaschine deiner Wahl ... ich kopiere jetzt hier bewusst nicht stumpf die Kommandos rein, weil das auch zu sehr unerwarteten Ergebnissen führen kann ... daher solltest du wissen was du da machst und wie du das revidierst !!! daher wirklich erst bitte einlesen ... wenn du gezielt dann Fragen hast, gerne ... aber mit Bqackground dann bitte
 
wenn die iGPU in einer eigenen iommu ist (was nur durch ACS überhaupt möglich wäre wenn ... und das auch nur mit "Gewalt" und ggf. "Nebeneffekten") und Unraid diese nicht mehr für sich beansprucht (Start Parameter und / oder beim boot vfio bind das ...) ... dann kannst du testen was passiert wenn eine VM diese nutzt ...
 
Vorher brauchst du da nicht weitermachen ...
 
Du solltest wissen, das ACS zwar softwareseitig splitten kann ... aber Hardware ist Hardware ... und wenn die iGPU dann evtl. ... und alles was dran hängt mit isoliert wird ... kann es passieren das nichts mehr geht, nur als Info nochmals vorweg ... daher ist das Thema iGPU in einer VM ... dafür gibt es vgpu (Intel) oder dGPU (also eine echt Grafikkarte, aber auch da ist Nvidia pflegeleichter) ...

zumindest nicht deine Frage "hidden" setzen wo dann keiner sieht ...

wo hast du das gelesen ?
 
unter /mnt/user/remotes ... wäre sicherlich falsch ...
 
und du weißt schon dass der Pfad auch einfach eingetragen werden kann wenn du /mnt/remotes/was_auch_immer nutzen willst ...
 
und remote Pfade einzubinden ist meist keine gute Idee, wird ja aber seine Gründe haben ...

wunderbar
 
hier als solution, die "funktionierende" Anleitung ...
 
 
ist im Support Thread auch angepinnt

ja ...
 
wie willst du das machen ? sshpass oder du setzt dich mit dem thema key exchange auseinaner (empfohlen)
google Suche, ssh key exchange
 
das wo liegt ? auf dem Unraid Server oder auf dem raspi ?
 
Beispiel, lokaler Server (wobei sich sudo für mich fraglich stellt wenn als root eingeloggt ... aber ok), siehe nächsten Punkt
 
ssh root@raspi 'echo "rootpass" | sudo -Sv && bash -s' < local_script.sh  
siehe vorherigen Punkt ...
 
in Zukunft, "zu Ende gedacht" ... mehr Infos sind hilfreich um effektiv helfen zu können ...
 
und es gibt einen extra user scripts Thread wo bereits viele viele Beispiele sind ... und viele Ideen bereits mal umgesetzt wurden

da sind bereits die beta RC Releases mehr oder weniger stable ... macht 0 Sinn

ich frage nur nochmals nach, das passt so ?
 
ist nicht video und Video ?

 
mover hat jetzt auch etwas Musik moved ...  da passt auch alles.
 
also, wenn ich die angenommene Video.cfg öffne sehe ich auch saubere Share settings, daher schätze ich kollidiert das mit der effektiven Video Share ... welche keine echte Konfiguration hat ...
 
die mit großem V ... existiert nicht, wäre aber konfiguriert ...
 

 
die echte mit kleinem v ... existiert, ist aber nicht konfiguriert ...
 

 
daher der Hinweis oben, wirklich aufräumen ... Share nochmals konfigurieren ... und speichern (änder mal was in den settings und direkt wieder retour und speicher, NACHDEM du die Video.cfg (groß geschrieben) entfernt hast ... (Reste aus deinen Tests und Anfängen schätze ich mal).
 
sofern ich mit meiner Annahme richtig liege dass dies beides Video sein soll

hab Ihn angepasst und die Namen aus deinem screen entfernt, nur als Info
 
das ist zwar nicht die Norm, sollte aber passen ... da liegt auch deine Konfiguration ... Beispiel
 

 
daher dürfte es kein "redo" von vorne geben, ein Update ist übrigens nichts anderes als den Docker löschen und neu ...
prüf mal bitte ob es bei dir in /mnt/user/paperless/data auch so aussieht ...
 
sprich, wenn der Docker updated, neu erstellt wird, ... dann sollte immer alles so wie vorher sein, etwas verwunderlich ...
Start Parameter sind auf dem Stick
Persistent data normal unter /appdata, in dem Fall unter /paperless ...
 
was ich sehe, du nutzt als cache btrfs ... was leider gerne Fehleranfällig ist ... ich sehe zwar nichts kritisches in den logs, aber ich würde leider empfehlen den in xfs zu wandeln ... da du eh nur single drive nutzt ... und kein raid_N pool.
 
Falls du den Versuch machen willst ...
 
1/ Settings, Docker, Service Stop
2/ Settings, VM, Service Stop (auch wenn keine VM läuft)
3/ Backup der Daten vom cache, alles außer /mnt/user/system/docker/... wobei dies bei dir anscheinend eh auf dem array liegt
>>> was nicht unbedingt empfohlen ist, aber egal
>>> mit dem file manager beispielsweise die Ordner auf einen Platz im Array rüber oder auf eine externe USB Platte oder ...
4/ wenn alles weg ist, array stop, disk aus dem cache pool entfernen
5/ disk ist jetzt unten bei unassigned devices, dort das rote x (remove partition), danach format in XFS
6/ wenn erledigt, die disk wieder im cache definieren, array start
7/ Backup der Daten aus 3/ wieder retour spielen
8/ Settings, Docker, Service Start
9/ schauen ...
 
was ich umstellen würde, diese beiden Shares gehören normal nicht unbedingt ins Array ...
 

 
und was ist der Share "root" ... ich schätze da ist schonmal grundsätzlich was schief gelaufen falls du den nicht selbst angelegt hast ... bewusst ...
 
so wäre der "gängige" Pfad hierzu ... nur als Info
 

 
ich sehe mal keinen echten Konfigurationsfehler bei Dir, nur btrfs und die nicht ganz glückliche Positionierung diverser Shares ...

genau so ... einen Reverse Proxy davor, der bekommt den HTTP, HTTPS Port ...  ab da dann "intern" entweder lokal auf weitere Dienste wie dein Vaultwarden oder intern auf eine separate LAN Maschine wie jetzt Nextcloud bei dir (davon ausgehend der NPM würde auf Unraid laufen).

Zweite Platte rein oder dran als unassigned device
 
VM und Docker Dienst aus 
 
Alles kopieren, Server herunter fahren, umbauen, Server starten, neue config, Platte zuweisen, Array starten, Dienste starten, fertig.

so wie es bereits hier stand ... /tmp ist wohl nicht /boot (stick)
 
wie auch immer du darauf kommst, Nein ... da schreibt nichts auf den Stick ...
 
verstanden ?

die 3 Shares erstellen
 
Media, data, privat (es ist überigens /mnt/user/... )
 
danach einfach den Rest da rein schieben, entweder manuell oder mit einem Tool deiner Wahl ...
 
ich sag mal stumpf per Terminal als Beispiel
 
mv /mnt/user/Serien/ /mnt/user/Media/  
verschiebt den Ordner Serien samt Inhalt in den Ordner Media (sofern vorhanden), daher vorher anlegen !!! und ggf. auf allen disks wo Daten von dem Share liegen auch, daher würde ich sogar eher vorschlagen um Stück für Stück zu machen ...
 
mkdir /mnt/cache/Media mkdir /mnt/disk1/Media ... mv /mnt/cache/Serien/ /mnt/cache/Media/ mv /mnt/disk1/Serien/ /mnt/disk1/Media/ ...  

kurz, wenn manuell vergeben (kein DHCP), dann ja  was auch die bevorzugte Methode wäre.
 
übrigens, wie bei jedem Gerät welches man manuell eingerichtet hat.
 
 
1/ Docker Dienst Stop
2/ Settings, Network, alles statisch raus, auf DHCP umstellen
3/ Router Einstellungen vornehmen (IP, DHCP Bereiche, ... definieren, umsetzen)
4/ Schauen welche IP Unraid bekommen hat, auf der dann verbinden
5/ Settings, Network, wieder die "neuen" statischen Werte fixieren
6/ Docker Dienst Start (ggf, schauen ob die neue Range auch übernommen wurde), bei den custom ... edit, IPs umstellen auf die gewünschte neue ...
 
das war es, evtl. wäre ein Neustart nötig (sollte normal nicht sein)
 
Notfallplan falls nichts gehen sollte, Server herunter fahren, Stick abziehen, an einen anderen Gerät anstöpseln, die Datei network.cfg unter /config löschen, Stick sauber trennen, wieder an den Server, starten ... Netzwerk ist "jungfräulich" und dann ab Punkt 4 starten.

das Forum hat übrigens eine Suche, oben rechts, Beispiel
 
 

dann pack alles ins Array inkl. USB und leb mit den evtl. Ausfällen welche bei USB gerne passieren, wenn das Video es empfiehlt ...
 
<Sarkasmus an> du kannst auch eine USB als Parity nehmen, wird dann noch besser und performanter ... <Sarkasmus aus>
 
also, probier es aus, Infos hast du, gehen tut es ... wie es läuft wird deine Erfahrung zeigen, bloß bitte keine Support Anfragen hierzu wenn es crasht, hängt, ...
langsam ist, usw usw ... du weißt jetzt warum

nope, das wäre dann sogar richtig

"normal" passiert das nur wenn vorher manuell etwas gemacht wurde, dann "überschreibt" das webui und setzt wieder die Standards ...
 
Lösung wenn es keine komplexe VM ist, neue VM erstellen mit deinen CPU, RAM Settings, auf die vorhandene vdisk verweisen ... dann sollte das erschlagen sein ...
 
wenn es etwas komplexer ist, vorher sicherheitshalber Backup der vdisk machen  nicht das der boot Part abgeschossen wird ...

Grundsätzlich, Nein
 
Und wenn steht alles in den changelogs

daher in den richtigen Teil verschoben ... in Zukunft bitte etwas darauf achten, Danke.
 
dazu die vdsm readme lesen https://github.com/vdsm/virtual-dsm
 
über den Sinn eine NAS Software als Docker auf einem NAS laufen zu lassen ... naja  aber ja, du bist nicht der einzige der wegen Photos vdsm nutzt
die meisten nutzen immich mittlerweile wo das Thema Photos etwas "schicker" möchten.
 
das solltest du eher im vdsm Forum hinterfragem, aber es ist ein Docker ... da stellt sich die Frage normal nicht.
 
vdsm nutzt als "disk" ein Image wenn ich mich recht erinnere, sprich, nicht so einfach ohne den Docker an seine Bilder zu kommen wenn mal was ist da die ja nicht "lose" auf dem Unraid NAS liegen sondern innerhalb eines Images was in vdsm mounted ist ...
 
 

also in der Konstellation, ich weiß ja nicht ob neue Platten kommen sollen, wie der pool aussehen soll, usw ...
 
wäre meine Vorgehensweise
 
1/ Docker Service stop, VM Service Stop, dann array stop
2/ tools, new config, deine aktuell eine disk als pool zuweisen anstelle array, die 2. (aktuelle parity) als 2. pool zuweisen
3/ array start
4/ Shares prüfen bzgl. primary, secondary > anpassen
5/ Docker, VM Settings prüfen bzgl. pool Zuweisung > anpassen
6/ array starten, fertig.
 

es gibt auch einen fertigen Docker ... falls dies nicht bekannt ist.
 
Du kannst jetzt versuchen alle fehlenden Abhängigkeiten zu eruieren und entsprechend zu installieren, dazu dann ein script erstellen was bei jedem Start alles installiert, oder auf den fertigen Docker aus CA (oder einem anderen fertigen) wechseln ...

den USB Stick um ganz sicher zu sein, wobei unter previous das "alte" Base OS gesichert wird um einfach wieder retour gehen zu können ...
 
und, changelog lesen ... ob was zutrifft und ggf. umsetzen.

ja, nur USB ist nicht so flott, daher ... (siehe unten)
 
mach eine Sicherung des /config Ordners vom Stick
 
die Freigaben kommen automatisch mit den Daten retour, daher nicht wundern wenn anfangs keine da sind wenn du erst new config machst
 
ist ok, wäre jetzt nicht meine Wahl, einfach den File Manager nehmen oder direkt im Terminal
aber wenn man sich in mc wohlfühlt, passt !
 
ja, wäre schneller als USB  siehe oben
 
abschließend, du kannst auch jetzt aus dem array einfach auf eine oder drei UAD kopieren .. dann hast du weniger Ausfallzeit beim Umstellen ...
dann new config machen wie du es beschrieben hast, zuweisen, fertig ...
 
Merken (screenshot) auf welcher/n UAD die Daten liegen dass diese dann nicht als Parity genommen wird.

naja, da gibt es nicht viel ... 1G ok, 2.5G nicht ok ...
 
macht es denn verbrauchstechnisch effektiv was aus ? bzw wieviel ?
 
am Ende ist das wohl ein Treiber Thema was so schwer zu lösen ist ... man könnte noch einen anderen switch testen ob ...
dieser sich ggf. anders verhält ... aber unwahrscheinlich.
 
ist übrigens öfters so, mehr Leistung, weniger Effizienz, auch im idle ...