Virtio Treiber

  • Was überträgst du den für Daten vom NB zum NAS das du solche Datenraten erzielen musst (willst)?

    Meine Antwort auf deine Frage passt dann auch nicht in diesen Thread...


    Bei RAW-Fotos und 4K-Videos macht es schon einen großen Unterschied, wie schnell die Daten übertragen und auch verarbeitet werden können. Thunderbolt 3 mit 40Gb/s bringt mir nicht den großen Vorteil, wenn die Daten auf dem NAS-Server nicht ausreichend schnell geschrieben und gelesen werden können. Da sollte schon beides zusammenpassen. Das durchaus gelungene Marketing zum Thunderbolt 3 von QNAP hat mich dabei ein wenig in die Irre geführt, weil die jeweilige Anbindung mit PCIe 2.0 x4 die möglichen Datenraten massiv ausbremst. Deshalb meine ständigen Umrechnungen zwischen Gb/s und MB/s um sicher zu gehen, dass ich keinen Denkfehler mache. Hinzukommt, dass die Celeron CPU der TS-453BT3 und 8GB RAM für einen Windows Server 2016 Essentials ziemlich mager sind. Aber auch mit der TVS-882BRT3 lässt sich Thunderbolt 3 nicht ausreizen. Die Idee auf der Produktseite finde ich super, aber bei der jeweiligen Anbindung müsste QNAP nochmals deutlich nachlegen, um auch die Geschwindigkeit von NVMe SSDs nutzen zu können.


    Ich habe mich jetzt für einen HighPoint SSD7101 Controller (bis zu 4x NVMe SSDs im RAID0, 1 oder 5 an PCIe 3.0 x16) in einem Rechner mit AMD Ryzen Threadripper entschieden. Dort können bis zu 64 Lanes direkt mit der CPU verbunden werden, ohne durch DMI 3.0 ausgebremst zu werden. Mit 4 Samsung 960 Pro werden bis zu 13.500MB/s erreicht. Aber selbst mit zunächst nur 2 Samsung 960 Evo sollte auch die Thunderbolt 3 Verbindung mit 40Gb/s ausgereizt werden, um meine Daten zu übertragen und damit arbeiten zu können. Die eigentliche Datensicherung kann dann im Hintergrund auf die WD Red HDDs erfolgen. Dafür sehe ich die Geschwindigkeit weniger kritisch.

  • @carsten_h


    Deine Beschreibung vom 12. April 2018 war Super!!!

    Die hat bei mir genau so funktioniert!


    Jetzt muss ich nur noch das Problem mit dem Tastaturlayout lösen....

    VM-Einstellung = Deutsch

    VM-WIN 10 64bit = Deutsch


    Tippen auf der Tastatur... Englisch... arg....

  • Begreifen muss man das nicht...

    Ich hatte die Anleitung schon mal vor ein paar Jahren für die Einrichtung der VM's auf meiner TS-453A genutzt.

    Ich hatte auch die Vorgehensweise auch noch behalten.

    Da ich meine VM's nun auf mein stärkeres TVS-882 umgezogen hatte, das Win10 aber vorher auch schon nicht mehr gestartet ist, ich denke das das an einem Update der VS lag, hatten ja einige andere auch berichtet, hatte ich meine Win10-VM, da sie auch auf dem TVS-882 auch nicht laufen wollte, neu aufgesetzt...

    Und siehe da, trotz dessen das ich im 2. CD die Guest-Tools drin hatte, wollte Win10 die Virtio-Treiber partout nicht anerkennen und ließ diese mich nicht installieren, so das ich Win10 erstmals hinter eine SATA-Schnittstelle packen musste.

    Weil, nicht schlimm, dann beschreite ich wieder den Weg mit der temp. 2.FP und verpasse dem die Virtio-Treiber und schiebe der ersten, noch SATA-Platte, nach einem Neustart die Virtio-Schnittstelle unter...

    Aber nix ging, selbst mit der mir bekannten neuesten Version der virtio-win-0.1.164.iso, wollte Win10 nicht brav starten.

    Irgendwas muss ich dann aber veranstaltet haben, plötzlich hat es geklappt. Wie auch immer...

    Aber wie hieß es doch gleich?

    Man kann alles essen, braucht aber nicht alles wissen, oder? :cup:


    Weiß jemand wie sich das mit den Guest-Tools verhält? Sprich wie fleißig updatet QNAP die immer? Beziehen sie sich auch auf die aktuellen Versionen, oder ist es besser die iso von Fedora, etc zu nutzen?

    Bzw. welche nutzt Ihr denn so?

  • Die Guesttools sind tatsächlich die neueste "stable" Version. Es gibt zwar eine neuere Version der Treiber, die werden aber nach wie vor als "beta" geführt - von daher stellt QNAP an der Stelle die richtige Version bereit.



    Gruß,


    Lauri

  • kann mir jemand erklären wie man die hinzugefügte 2. Platte wieder aus dem System entfernt wenn man den Treiber installiert hat?


    Die Festplatten Datei löschen/umbenennen bringt nichts, dann startet Windows nicht mehr.

  • kann mir jemand erklären wie man die hinzugefügte 2. Platte wieder aus dem System entfernt wenn man den Treiber installiert hat?

    Welches System meinst du denn? In der Virtualiszation Station auf der NAS oder IN deinem Gast Betriebssystem

    (welches das auch immer sein sollte, Win7, Win10, Win2012, ...)?


    Falls du die VS meinst, steht das im Post #26

    Jetzt wieder die VM herunterfahren.

    In der Virtualization Station die HDD 2 löschen (mit dem kleinen "x" am Ende der Zeile mit HDD 2) und bei der HDD 1 VirtIO eintragen.


    Falls du die Windows VM meinst, da würde ich mal in den Gerätemanager reingehen ...

    Wobei es eigentlich egal sein müsste. Windows ist es ziemlich egal, wenn eine Festplatte beim Hochfahren nicht mehr da ist, solange es nicht die Systemdisk (!) ist, die dann fehlt ...

  • Lies mal da nach Cache-Algorithmus, dann sollte alles klar sein.


    Aber am besten ist es, wenn du selber noch einen Leistungstest (CrystalDiskMark, etc.) mit der VM machst und die Cache Einstellungen durchgehst ;)


    Macht nämlich einen großen Unterschied, ob deine virtuelle HDD auf einer SSD liegt oder auf einer HDD, je nachdem bringt der Cache was, oder macht es langsamer ...

  • Ok, gelesen - habe ein TVS-1282 mit I7 32Gb Mem, die Virtuelle liegt auf einer SSD....was macht da deiner Meinung nach am meisten Sinn?

  • Sinn macht das, was DU haben willst ;)

    1. Teste mit der VM, ob du einen Unterschied merkst (write-back sollte schneller sein, die I/O completition kommt, sobald die Daten im Cache sind)
    2. Überlege ob du Sicherheit willst (write-through ist sicherer, die I/O completition kommt erst, wenn die Daten auf der Disk sind)

    Ich habe write-through genommen … VM-Image ist auf einer SSD, Cache ist bei mir ein NVMe M.2 RAID1 ...

  • Ich bin bis vor einiger Zeit auch mit write-through gefahren.

    Nachdem mir aber die Win10-VM aus unerklärlichen Gründen nach einem FW-Update, oder Virtualisation-Station-Update, genauer lässt es sich leider nicht mehr nachvollziehen, "gestorben" ist, bin ich auf write-back geswitcht.

    Unerklärliche Gründe deshalb, da selbst eine Sicherung der VM nicht mehr starten wollte. Und die war definitiv von vor den Updates.

    Und da das hier auch keiner so richtig nachvollziehen konnte, warum bei einigen, mit genau den selben QNAP's nach den Updates, die VM's "gestorben" sind und bei anderen nicht, hatte ich etwas den Cache in meine Vermutung bekommen.

    Und seit ich write-back nutze... Bisher alles gut.

    Hat natürlich noch nix zu sagen.

    Vorher liefen meine VM's auch mit write-through jahrelang...

  • Und seit ich write-back nutze... Bisher alles gut.

    Hast du mal einen Performancetest durchgeführt, none, back, through oder force-back?


    Müsste ich bei mir mal bei Gelegenheit anwerfen und schauen, ob sich die Unterschiede spürbar auswirken.

    Wobei write-back ja eher die unsichere Methode ist, da würde ich gleich auf "none" gehen, wenn mir die VM's "abrauchen"

  • Nein, so noch nicht. Ich bin da auch nicht auf ner NVMe, so wie Du, sondern ganz einfach auf SATA.

    Aber spürbare Unterschiede hatte ich nur von write-through auf write-back mitbekommen. Aber nicht so gravierend, das die mich gestört hätten.

    Ich war ja früher auf dem TS-453A auf Spindel mit den VM's. Und da sind die SSD's ein Riesensprung.

    Und zwischen none und write-back hatte ich nix gemerkt...

    Schade nur, das auf meiner Vista-VM die Tools nicht mehr unterstützt werden. Somit laufe ich da auf IDE. Aber das ist für Vista auf der SSD auch noch schnell genug, im Vergleich wo die VM auch noch auf der Spindel lag.

  • Schade nur, das auf meiner Vista-VM die Tools nicht mehr unterstützt werden

    Moment mal, das sollte zu schaffen sein!

    Nach anfänglichen Hürden habe ich das sogar auf meinen WinXP VM's hinbekommen ;)


    Da hatte ich auch monatelang nur IDE, irgendwann habe ich nochmals die Anleitung hier (Post #26 von carsten_h ) zum Thema VirtIO einbinden durchgelesen und damit klappte es auch bei den ALTEN (!) WinXP's. Also sollte Vista noch allemal funktionieren.

    Einmal editiert, zuletzt von RedDiabolo ()

  • Das kenne ich ja auch, aber genau bei den Tools meint er das es ein nicht unterstütztes OS wäre...

    Bei Win10 kein Thema. Bei Vista... WinXP hatte ich damals auch mal gemeint hinbekommen zu haben... Deshalb hatte ich ja schon nach der Version der Treiber gefragt. Scheinbar wurden die jetzt rausgeworfen... Zumindest die Vista64-Teile...

  • So, habe jetzt mit meiner WinXP VM (4 Cores, auf RAID1 SSD, mit RAID1 NVMe Cache) die verschiedenen Cache-Einstellungen der VirtIO-Treiber durchgetestet:



    2019-04-04 21_48_16-none.png

    Cache-Modus: None

    2019-04-04 22_03_07-back.png

    Cache-Modus: Writeback

    2019-04-04 21_35_38-through.png

    Cache-Modus: Writethrough

    2019-04-04 22_13_39-force-back.png

    Cache-Modus: Force Writeback


    Schaue ich mir die Leistungsmessung so an, dann ist für mich ab jetzt der Cache-Modus Writeback der richtige. Ist doch etwas schneller als ich dachte (im Vergleich zum Writethrough)


    Allerdings muss man dabei auch beachten, dass ich als Cache 2 NVMe M.2 im RAID1 verwende und in erster Linie die Leistung der NVMe ausschlaggebend ist!


    Ohne Cache (None) ist es so ziemlich genau die Leistung, die die SSD hier bringen kann.


    Wobei beim Force-Writeback, der schnellsten Variante, noch eine Warnung dazu kommt! Ist also auch nicht das gelbe vom Ei :/

    2019-04-04 22_04_18-Flush.png