Verstehe ich dich richtig?
Du meinst du hast deine VM auf einem RAID1 SSD laufen und denkst weil du ein RAID 1 NVMe Cache auf dem NAS eingerichtet hast das die VM dieses als Writeback Cache nutzt?
Ich denke da bringst du 2 verschiedene „Cache“ durcheinander.
Der Cache der mit Writethrough oder Writeback eingestellt wird ist im RAM und hat nichts mit dem Lese oder Schreibcache zu tun den du im Speichermanager des NAS einrichten kannst.
Was ich denke ist eigentlich wurscht, ich schaue mir im Speichermanager die Cacheverwaltung an (read/write Trefferquote) und starte dann den Performancetest in der NAS.
Wenn dann ZEITGLEICH der Cache (NVMe) auf 100% hochgeht und beim Lesen auch die entsprechende Trefferquote anzeigt, dann interpretiere ich das als Zugriff auf den R/W Cache im NVMe RAID1.
Stelle ich den Cache-Modus auf None, zeigt auch der R/W Cache keinen Muckser ...
Wie würdest du das interpretieren?
PS.: Wenn ich den R/W Cache deaktiviere habe ich nicht mehr diese Übertragungsraten ... da brauche ich mir nichts dabei zu denken, da Teste ich einfach ein paar Sachen aus und nehme dann genau die Einstellungen, die am meisten bringen.
Ja wenn du das so beschreibst würde ich dir zustimmen.
Dann verstehe ich es wohl falsch.
Sorry.
Ja wenn du das so beschreibst würde ich dir zustimmen.
Kein Problem, so ganz verstanden habe ich es auch noch nie, ich interpretiere blos die Reaktionen auf der NAS ...
Aber um (auch für mich) Klarheit zu schaffen, habe ich per Ticket bei QNAP nachgefragt. Werde die Antwort hier posten (sobald sie denn kommt 
)
Edit "Antwort" von QNAP ist da, aber ich kann damit nichts anfangen 
Zitat von QNAP Technical SupportAnleitung Vitualization Station: https://www.qnap.com/de-de/how…virtualization-station-3/
Als KVM wird von uns QEMU verwendet: https://www.qemu.org/
QEMU kümmert sich um die Verwaltung des Speichers und des Cache.
Bei Fragen zur Verwaltung bzw. zum Management wenden Sie sich bitte an QEMU.
Hmm, ja ... im erstem Link lese ich was vom "Seiten-Cach" raus, sagt mir aber trotzdem nicht, ob nur RAM und/oder I/O Cache:
Es gibt drei Cachemodi: "Writeback", "Writethrough" und "Ohne".
"Writeback" nutzt den Seiten-Cache des NAS. Wenn die Kapazität des NAS-Cache erschöpft ist, werden alle Cache-Daten auf die Festplatte zurückgeschrieben. Im Vergleich zu "Writethrough" hat "Writeback" eine höhere Transferrate. Allerdings ist "Writethrough" sicherer, da es Daten direkt auf die Festplatten schreibt, indem es den Schreibcache verwendet und Datenverlust vermeidet, wenn unerwartete Ereignisse auftreten. Mit "Ohne" wird der NAS-Cache umgangen; damit liegt die Transferrate zwischen der von "Writeback" und "Writethrough".
Im zweitem Link (QEMU) les ich viel über den cache, aber auch nicht, ob RAM oder I/O:
Mod: Nicht deklariertes Zitat ohne Quellenangabe gelöscht
"IO directly to guest memory" könnte ich jetzt als "nur RAM" interpretieren, aber weshalb schlägt dann mein I/O Cache synchron mit an?
Ich glaube der Support hat es selber auch nicht ganz verstanden und verweist mich höfflich an QEMU 
Ich hab mir das mit dem Cache eben nochmals durch den Kopf gehen lassen.
Eigentlich wäre doch aber, in Bezug auf mein Problem in der Vergangenheit, das ich meine Win10-VM partout nicht zum wiederbeleben bekommen habe, None die sicherste Variante.
Bei mir war die VM nach einem QTS- und/oder einem VS-Update nicht mehr gestartet. Selbst eine alte Sicherung der VM kam nicht mehr hoch.
Meine steinalte Vista-VM hatte das Ganze nicht gejuckt, die lief immer fleißig weiter, nur die Win10-VM war betroffen.
Wenn ich nun mal den Verdacht Richtung QTS oder VS schiebe, wäre es doch wohl sicherer den Cache ganz außen vor zu lassen.
OK; nach @ RedDiabolo seinen Test ist das natürlich nur das was die FP an sich selber schafft, aber mir wäre es ja relativ egal. Ich bin ja nun nicht der Geschwindigkeits-Junkie...
Und, jetzt hab ich die ganzen Probleme mit meiner Vista-VM hinbekommen.
Durch mein ewiges "Umgeziehe", hatten sich so viele Netzwerkadapter im Hintergrund angesammelt...
Ich hatte es hinbekommen, das ich doch die Virtio-Treiber reinballern konnte... Ich habe ihm einfach die Serverversion vom 2008er untergejubelt. Und den hatte er dann endlich klaglos übernommen. Ich musste ihn aber dazu zwingen.
Dann hab ich sämtliche Adapter aus dem Gerätemanager rausgehauen, die Registry durch geackert, nach LAN-Verbindungen, alles weg gehauen...
Ich hatte mich nämlich auch immer gewundert, warum er mir immer wieder LAN-Adapter2 installiert hatte und der sich nicht umbenennen ließ, obwohl kein anderer da war...
Und nach einem Neustart dann sauber den Netzwerkadapter mit dem Virtio-Treiber neu reingebracht.
Und nach dieser "Groß-reine-mach"-Aktion, bumm…
Nach Jahren totem Update und alle möglichen anderen Problemen, jetzt sprach Update wieder mit MS...
Eigentlich wäre doch aber, in Bezug auf mein Problem in der Vergangenheit, das ich meine Win10-VM partout nicht zum wiederbeleben bekommen habe, None die sicherste Variante.
So, nun habe ich genau das verifizieren können.
Nachdem die VM einige Zeit lief, auch Updates von MS gezogen, alles gut (ohne Cache), habe ich dann erneut den Cache eingeschaltet.
Und nun nach erneutem QTS- und VS-Update ist die VM zwar wieder gestartet, als ich dann aber einen Neustart initialisiert hatte, schlug die Win-Systemreparatur fehl, obwohl es für mich keinen ersichtlichen Grund gab, überhaupt das System zu reparieren.
Es half auch nichts, einfach den Cache wieder auszuschalten, die VM wollte partout nicht mehr hochkommen.
Erst wenn ich den Cache ausgeschaltet gelassen habe und dann die alte Sicherung wieder reingebracht habe ist die VM wieder gestartet.
Ich vermute somit, das es hier ein Kompatibilitätsproblem zwischen dem Cache-Modus und Win10 gibt. Die Vista-VM lässt dies alles ja klaglos an sich vorbei, die läuft nach wie vor problemlos. Die beiden laufen parallel weil ich gerade am Schauen bin wegen einem Event. Upgrade meiner CPU im Qnap und dabei ist mir das Ganze aufgefallen.
Und nun nach erneutem QTS- und VS-Update ist die VM zwar wieder gestartet, als ich dann aber einen Neustart initialisiert hatte, schlug die Win-Systemreparatur fehl, obwohl es für mich keinen ersichtlichen Grund gab, überhaupt das System zu reparieren.
Es half auch nichts, einfach den Cache wieder auszuschalten, die VM wollte partout nicht mehr hochkommen.
Erst wenn ich den Cache ausgeschaltet gelassen habe und dann die alte Sicherung wieder reingebracht habe ist die VM wieder gestartet.
Habe gerade aktuell praktisch identische Probleme mit meinen Win10 VMs. Beispielsweise bei aktivieren meiner RX480-Grafikkarte geht Windows (erfolglos) in den Reparaturmodus, nach deaktivieren starte sie problemlos. Gestern identisches Problem bei einer Kopie dieses Systems ohne RX480 beim installieren einer weiteren (virtuellen) Festplatte. Bin mir nicht sicher, was jetzt an welchem Update liegt, da sich bei mir sowohl Win10 als auch VS die Tage aktualisiert haben.
Der Thread ist schon etwas älter, aber ich versuche mal mein Glück.
Ich habe eine VM mit dem Image eines Windows-Server 2019 erstellt.
2 CD-ROM Geräte eingebunden. Eines mit dem Image des Windows, in dem anderen die Guest-Tools.
Die HDD hat 50GB, Cachemodus "Writeback" und Schnittstelle "VirtIO".
Windows sagt mir beim Setup, daß keine Gerätetreiber vorhanden sind.
Leider kann ich in den Ordnern der Guest-Tool - CD keine funktionierenden finden.
QNAP (https://www.qnap.com/de-de/how…irtualization-station-ein) spricht hier von der D:\WIN7\X86\VIOSTOR.INF.
Ich nehme hier aber den "2k19/amd64/viostor.inf.
Nur wird damit keine verfügbare HDD zur Installtion gefunden.
Habe die Tage Win 10 als VM installiert, da habe ich einfach alle in dem Ordner durch probiert, einer hatte dann funktioniert.
Dann nimm den umständlichen Weg.
Erst Windows Server ganz normal auf IDE Schnittstelle installieren und einmal booten.
Wenn das alles fertig ist fügst du eine zweite HDD (VirtIO) mit 1 GB Speicher hinzu und bootest die VM nochmal hoch. Dann kannst du die Treiber von der Guest CD installieren. Dann die VM herunterfahren und jetzt solltest du die erste HDD in VirtIO ändern können. Die zweite HDD kannst du wieder löschen.
So hat es bei mir bisher immer funktioniert.
Danke für die Antwort Crazyhorse .
Habe ich natürlich schon vor dem Post probiert gehabt.
Also alle in dem 2k19/amd64-Ordner.
Funktioniert hat natürlich nichts.
Dann mache es wie
Dann nimm den umständlichen weg.
beschreibt, so geht es auch wenn das mit den Treibern mal zickt.
Wofür dient die zweite HDD? Und wie soll die Eingebunden werden? Bzgl Cache und Schnittstelle?
Wenn ich von der Guest-Tool-CD die Treiber nachinstallieren kann ist doch eine zweite HDD überflüssig oder?
Wofür dient die zweite HDD?
Die dient dazu erstmal den Treiber auf dem virt. System zu haben.
Die Systemplatte ganz normal als IDE und danach, wenn das System läuft und die 2. Platte mit dem Virtio in Betrieb genommen wurde, der Systemplatte den Treiber "unterjubeln"...
Wofür dient die zweite HDD? Und wie soll die Eingebunden werden? Bzgl Cache und Schnittstelle?
Die muss mit VirtIO Schnittstelle konfiguriert werden. Sry, hatte ich erst vergessen dazuzuschreiben.
Wenn ich von der Guest-Tool-CD die Treiber nachinstallieren kann ist doch eine zweite HDD überflüssig oder?
Ich glaube es werden nur die benötigten Treiber installiert. Damit tut er dann den VirtIO Treiber für Speicherlaufwerke installieren.
Der Chachemodus ist erstmal egal, der lässt sich nachher immer ändern.
Die dient dazu erstmal den Treiber auf dem virt. System zu haben.
Und genau das verstehe ich nicht.
Kann ich das auf IDE-HDD installiertem System nicht nachträglich umstellen auf "VirtIO" und die Treiber im laufenden Betrieb nachinstallieren? Und wie bekomme ich die Treiber von der CD auf die HDD?
Aber gut, ich installiere jetzt erstmal auf IDE.
@rednag Wenn Du das System mit IDE eingerichtet hast, fügst Du einfach eine 2.HDD dazu und nimmst bei der den Virtio-Controller.
Screenshot 2021-01-16 170248.jpg
Danach kannst Du dann die HDD1, also die Systemplatte dann in den VM-Einstellungen auch ändern, da das Gast-System nun die Virtio-Treiber hat.
Neustart des Gast natürlich Pflicht
Kann ich das auf IDE-HDD installiertem System nicht nachträglich umstellen auf "VirtIO" und die Treiber im laufenden Betrieb nachinstallieren?
Er bootet halt nicht, wenn du einfach auf VirtIO umstellst.
Die zweite HDD brauchst du, damit er von der IDE booten kann, aber noch eine VirtIO im System hat, für welche er die Treiber braucht.
Und wie bekomme ich die Treiber von der CD auf die HDD?
Einfach die CD einbinden und die Setup ausführen. Dann da alles anwählen (außer vielleicht UltraVNC) und er installiert dir die Treiber.
Eventuell geht es auch über den Gerätemanager direkt, wenn du da den Treiber auf der CD suchen lässt, aber das habe ich noch nicht getestet.
@rednag Schau hier nochmals, https://www.qnap.com/de-de/how…irtualization-station-ein
Auf dem Gast den Controller später updaten...
Screenshot 2021-01-16 171122.jpg
oder halt ändern.
