Die DS918+, DSM7, USB Ports, HDD Docks und der Wunsch nach einer etwas schnelleren Windows VM

[buzztee]

Ich habe aktuell eine voll bestückte DS918 mit 4x12/B HDD, 16 GB RAM, auf der diverse Dienste laufen: Docker, Backup, Plex/Jellyfin, ein paar Linux VM. Vor einiger Zeit habe ich mal eine WIndows 10 VM hochgezogen, die sich klammheimlich als sehr praktische Admin-VM gemausert hat.

Lange Rede, kurzer Sinn: Die Windows VM läuft solider, soll aber flotter werden.

Als Bottleneck habe erstmal ich die HDD´s ausgemacht - läuft die Windows VM und ich nutze sie, rödeln die Platten arg rum. Arbeitsspeicher ist ausreichend vorhanden.

Jetzt hatte ich die Idee, die Windows VM auf eine SSD auszulagern - die eingebauten NVME Slots lassen sich ja nicht ohne weiteres als Volume nutzen, auf das ich die Platten der WIndows VM legen könnte. Da alle 4 Slots der DS belegt sind kann/will ich auch nicht ohne weiteres eine Platte rausnehmen

Leider sind auch die USB-Ports meiner DS schon belegt: 1x mit ner USB und 1x mit einem USB 2-Bay HDD-Dock, auf der ich regelmäßig Backups ablege. USB-Hubs funktionieren ja seit DSM7 nicht wirklich soweit ich weiss?

Ich habe nun überlegt, eine e-SATA 2-Bay (oder gleich 4-Bay?) HDD Dock zu kaufen, damit ein USB-Port frei wird. Daran würde ich eine SSD anschließen (passendes USB-Gehäuse habe ich noch), die Platte mit BTRS formatieren und dann schauen, ob man den als Storage in VMM nutzen kann - Oder ist genau da mein Denkfehler?

Weitere Optionen:
- größere DS mit 5 oder 6 Slots kaufen... Dazu bin ich noch nicht bereit
- Die WIndows VM irgendwo anders laufen lassen. Vielleicht auf nem Raspi 4 mit NVMe SSD? Da hat sich für meinen HomeAssistant sehr bewährt...

Welche anderen Ideen gibt es noch? Ich habe irgendwie das Gefühl viel zu kompliziert zu denken...

 

[Jim_OS]

- Die WIndows VM irgendwo anders laufen lassen. Vielleicht auf nem Raspi 4 mit NVMe SSD? Da hat sich für meinen HomeAssistant sehr bewährt...

Wo Du selber schon den Gedanken hast: Windows 10 auf einer Synology als VM ist m.M..n nicht wirklich performant. Statt dem Raspi würde ich (bzw. habe ich auch) dafür allerdings z.B. einen Intel NUC (oder Alternative) nehmen. Dann kämen auch noch solche Möglichkeiten wie Proxmox in Betracht, sprich darüber und damit ließe sich vieles realisieren. Also z.B. VMs für Jellyfin, Plex, Windows 10 usw.

Ein Synology NAS mit seinem VMM und Btrfs und den Einschränkungen durch CPU und RAM, ist für Virtualisierung nicht wirklich gut geeignet. Erst Recht nicht wenn man den Kosten-/Nutzenfaktor betrachtet.

Also statt jetzt viel Geld in die Erweiterung des NAS, oder in ein neues leistungsfähigere NAS zu stecken, würde ich das was geht auf einen Linux PC/Server auslagern und das NAS (nur noch) als NAS nutzen.


Nachtrag bzgl. Mini-PCs
Oder Du schaust mal nach solchen Teilen - Beispiel Amazon


So etwas gibt es oft z.B. auch günstig als Leasing-Rückläufer (refurbished) und mit so etwas bist Du bzgl. VMs wesentlich flexibler als mit jeder Synology. 16 - 32GB RAM reinpacken und ggf. eine größere SSD und zwischen so einem Teil und Deiner DS918+ liegen Geschwindigkeitstechnisch fast Welten. Einfach mal z.B. bei Amazon und ebay nach Mini-PC stöbern.

VG Jim

 

[NSFH]

Auf diesen kleinen NAS wird Win10 nie performant laufen. Es stellt sich allerdings die Frage was man mit der VM überhaupt anstellen will.
Dann ist ein NUC mit 400€ einfach zu teuer gegenüber einer SSD für 40€, die für eine VM bei Synology ein absoolutes Muss ist.

 

[Jim_OS]

Ja klar, wenn es ausschließlich darum geht das die Windows 10 VM etwas schneller laufen soll packt man 'ne SSD rein und gut ist. Da der TE aber erwähnt hatte,

auf der diverse Dienste laufen: Docker, Backup, Plex/Jellyfin, ein paar Linux VM. Vor einiger Zeit habe ich mal eine WIndows 10 VM hochgezogen,

sprich bereits jetzt schon div. Docker und VM Anwendungen laufen, würde ich dafür zu einer zusätzlichen Linux PC/Server Variante greifen, auf der ich das dann laufen lassen würde. Das hätte neben dem Geschwindigkeitsvorteil auch noch div. weitere Vorteile. Der einzige echte Nachteil wäre der Administrationsaufwand (z.B. für Proxmox) und der Stromverbrauch. Wobei man den bei Mini-PCs eigentlich fast vernachlässigen könnte. Auf keinen Fall würde ich, wie als Option ja ebenfalls angedacht/erwähnt, mir dafür ein neues NAS kaufen.

VG Jim

 

[buzztee]

Danke für Eure Hinweise, ich habe mich nach wie vor noch nicht entschieden, was die finale Lösung sein soll.

Die Windows VM ist quasi meine "Admin-VM", dort ist halt alles installiert und eingerichtet und im direkten Zugriff, was ich brauche. Die Maschine kommt in der Praxis nur vglw. selten zum Einsatz, ggf. nur ein oder zwei Mal am Tag, dann ein paar Tage vielleicht gar nicht. Ich greife teilweise von unterwegs via Guacamole/RDP auf die Maschine zu. Wichtig ist mir der Dauerbetrieb und die permanente Erreichbarkeit der VM
Die Performance ist tatsächlich eher nebensächlich, im großen und ganzen läuft die VM ja auch akzeptabel, aber ein bisschen flotter wäre schon nett. RAM und CPU auf der DS ist nicht das Thema. Die durchschnittliche CPU-Auslastung liegt unter 30%, und RAM ist auch mehr als genug zur Verfügung.. Es laufen 12 Docker Container dauerhaft, die meisten mit minimalen Anforderungen, und eine Linux Server VM als VPN-Gateway. Für mich habe ich eben als Flaschenhals den Plattenzugriff ausgemacht aus Sicht der Windows VM und ich habe dann in einer naiven Annahme, die VM einfach auf eine SSD zu schieben, gehofft das Verhalten zu verbessern.

ich habe im LAN übrigens nen Zotac Nano mit Windows laufen, der steht aber mit einem Bein/NIC in einem anderen Netz und dem möchte ich nicht die Rolle der Admin-VM geben. Testweise habe ich da mal VMWare Workstation drauf installiert und die WIndows VM dahin geschoben, aber das ist trotz SSD und ausreichend RAM deutlich langsamer als die VM auf das DS:
Noch ein Mini-PC/NUC/...ist derzeit eher nicht meine angestrebte Variante, mit der DS und dem Zotac Nano laufen bereits zwei Maschinen 24/7 und ich möchte den Stromverbrauch nicht ganz außer Acht lassen.

Danke an alle Denkanstöße, die haben mir zumindest insoweit geholfen, dass ich den Sinn des Ganzen nochmal von Grund auf neu bewerten möchte und auch gedanklich historisch gewachsenes nochmal hinterfrage.

P.S: Ein weiterer Gedanke war zwischenzeitlich, dass ich von meinen 4-Bay eine HD entnehme und dort ne SSD reinpacke - der freie Platz im Raid gibt das her. Nach einer Recherche habe ich aber herausgelesen, dass das Herausnehmen einer HDD aus dem Raid der Degraded-Status nicht geheilt werden kann - das ist inakzeptabel. Das NAS komplett neu aufbauen erscheint mir hier dann als Lösung für diesen Ansatz nicht angemessen.

 

[ctrlaltdelete]

Ich würde die NVME Slots als Speicherpool über die Konsole anlegen und diese als Volume für die VM nutzen, mit einem aktuellen Backup des Volumes bzw. der VM.

 

[buzztee]

Ich würde die NVME Slots als Speicherpool über die Konsole anlegen und diese als Volume für die VM nutzen, mit einem aktuellen Backup des Volumes bzw. der VM.

Nach meinem Informationsstand geht das nicht offiziell, d.h. man läuft Gefahr, dass das nach einem DSM-Update nicht mehr geht?
Ich habe diese Variante nur deshalb verworfen, weil es nicht offizell geht und ich in Sachen Verlässlichkeit skeptisch war.
Kannst auf auf eine Anleitung mit DSM7 verweisen?

 

[ctrlaltdelete]

siehe hier #180

 

[buzztee]

Ja, danke @ctrlaltdelete
ich hatte die Frage in dem Thread auch zur Konkretisierung gestellt, und #180 war genau die Antwort.

 

[buzztee]

Für die Referenz: Das Ergebnis meines Vorhabens habe ich in Post #182 und #183 zusammengefasst

 

[himitsu]

Ich habe diese Variante nur deshalb verworfen, weil es nicht offizell geht und ich in Sachen Verlässlichkeit skeptisch war.

Falls es doch mal kaputt geht, dann hast'e ja immernoch dein Backup davon (falls nicht vergessen).

 

[ctrlaltdelete]

@buzztee hast du die Pakete auch auf die NVME umgezogen?

 

[buzztee]

@buzztee hast du die Pakete auch auf die NVME umgezogen?

Nein, noch nicht. Muss ich mir noch Gedanken drüber machen. Ich habe vor ner Weile mal Pakete über die Konsole verschoben, konnte mich aber eben ad hoc nicht mehr an Details zum Vorgehen erinnern (Dienst stoppen, dann Move oder so, wenn ich mich recht erinnere, muss cih nochmal googlen) - das ist aber noch auf meiner Agenda das zu prüfen. Für einige Pakete Packages wie Plex und Emby erscheint mir das durchaus sinnvoll.

 

[ctrlaltdelete]

https://www.synology-forum.de/threads/apps-von-volume-x-nach-volume-y-verschieben.77896/
weiß aber nicht ob es unter DSM7 klappt, hatte es unter DSM6 benutzt und alle Pakete auf die NVME verschoben

 

[buzztee]

Ok, danke nochmal für den Hinweis - dort im Thread gibt es Hinweise, dass es mit DSM7 und dem Script Probleme geben kann.
Ich habe dann Plex und Emby von Hand über die Konsole verschoben, und nachdem ich das Standard-Installation Volume entsprechend geändert hatte, über Repair auf dem neuem Volume ans Laufen bekommen.
Ich bin noch skeptisch was Docker anbetrifft - Hier muss mEn der ganze Ordner /volumeX/@Docker/ verschoben werden. Ich weiss aber noch nicht, ob ich dafür vorher noch die Docker Container exportieren muss. Hat das schomal jemand durchlaufen und kann Tipps geben?
Diesen Forenbeitrag fand ich interessant: https://www.synoforum.com/threads/docker-migration-to-new-nas.2777/
Die restlichen Packages lasse ich auf dem alten Volume, einig VMM juckt mich noch auch auf die SSD zu verschieben.

/edit: Diese Anleitung habe ich eben gefunden, die klingt plausibel: https://www.synology-forum.de/threads/docker-migration-auf-neues-volume.112354/#post-916724

 

[himitsu]

Bei diesem Docker gibt es ein paar Besonderheiten, denn unter Btrfs verstecken sich darin mehrere Btrfs-SubVolumes.
Ebenso für VMM/LUN.
Bei VMM/LUN kommt noch der Spaß dazu, dass neben jeder Disk eine fette Datei liegt, die einen Link zum kompletten Volume darstellt (k.A. warum).

/volume1/@Docker/btrfs/subvolumes/****************************************************************

/volume1/@iSCSI/LUN/VDISK_BLUN/********-****-****-****-************
/volume1/@iSCSI/Snapshot/BLUN/********-****-****-****-************/********-****-****-****-************

/volume1/@sharesnap/***...***/GMT+**-****.**.**-**.**.**
/volume1/@tmp.del/**********/****.**********/****

Die letzten Beiden kann man wohl ignorieren/löschen, bzw. die Snapshots allgemein.


Im Notfall muß/sollte man drüben halt ebenso die Subvolumes erstellen.

btrfs subvolume list /volume1
btrfs subvolume create ...

Faule dürfen auch gern abkürzen: btrfs su li /volume1

 

[buzztee]

Danke @himitsu aber ich fürchte ich habe meine Docker-Installation völlig zerschossen. ganze am Ende hatte ich die doppelte Anzahl COntainer, viele mit "temp" Zusatz. Zum Glück habe ich die EInstellungen der Container, die Compose Scripte und das Docker Share noch.
Morgen deinstalliere ich Docker einmal komplett (mal schauen ob ich den @Docker@ folder komplett wegbekomme (über die Konsole gibts diverse "not permitted"-Meldungen trotz root.) und dann starte ich von Null, direkt auf der NVME und belebe die wichtigsten Container wieder.
Lernen durch Schmerz würde ich sagen.