[Sammelthread] Microsoft Hyper-V Stammtisch

So, es wird ernst(er). Für die nächste Testphase muss die Testumgebung erweitert werden für den Zugriff durch meinen Hauptsystem.

Dafür hab ich nach langer Zeit mal meinen Haupt-Server physisch geöffnet, wieder 4 NVME SSDs nachgesteckt und eine der beiden ConnectX-5. AMD's Epyc-Plattform mit den 128 Lanes (pro CPU) ist schon der Hammer. Da laufen jetzt u.a. 8 NVMEs (32 Lanes), 2x 100Gbit Dual-Port NICs (32 Lanes) und ein HBA (16 Lanes), alles unter ESXi per Passthrough durchgereicht an zurzeit 2 VMs: 1x meine "produktive" Storage-VM mit Solaris 11.4 (4x NVME + ConnectX-4 Dual-Port), und 1x die "Test" Storage-VM mit Windows Server 2022 (ebenso 4x NVME + ConnectX-5 DualPort).

Um mir das Leben für die Testphase etwas leichter zu machen, hab ich mich erst einmal für Server 2022 mit "Desktop Experience" entschieden. Geht ja erstmal nur um Test-Spielereien rund um ZFS, ReFS, VHDX über's Netz, SMBDirect, bisserl User-Management (ohne Domäne) usw. Ich scheue mich aktuell auch noch, mich komplett von Solaris zu verabschieden, also lasse ich für die Testphase einfach mal beide parallel laufen...

Grundvoraussetzungen sind da: Server 2022 installiert, Remotedesktop aktiviert, alle Spielzeuge vorhanden:

1709123275440.png


Für mehr reicht die Zeit leider gerade nicht. Vielleicht kann's ab Freitag/Wochenende weitergehen.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Oi... es wird gemunkelt zu Server 2025:

- Windows Server vNext delivers 90% more IOPS on NVMe SSDs
- NVMe over Fabric (NVMe-oF) support
- Storage Replica 3x performance improvement
- New ReFS native deduplication and compression, optimized for hot-data such as virtual machines

NVMe-of wäre ja schon hübsch, wenn man das irgendwie ins Homelab bekäme... :d
 
Bin gerade darüber gestolpert und erwähne es hier mal, weil mir nicht bekannt gewesen:

Wie man Nested Virtualization in Hyper-V aktiviert.
Code:
Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true

Aktuell habe ich eine pfSense VM in einem Proxmox VE laufen, welches wiederum unter Hyper-V läuft.
(y)
Capture.PNG
 
Zuletzt bearbeitet:
Auf der Suche nach der besten Verbindung zwischen Client und Storage habe ich nun einmal iSCSI gegen SMBdirect gegeneinander antreten lassen.

Kurzes Vorwort:

Um SMBdirect nutzen zu können, muss man - wie der Name schon sagt - offensichtlich irgendwie eine SMB-Verbindung nutzen. Das geht grundsätzlich natürlich mit einer einfachen SMB-Freigabe. Aber SMB-Freigaben mögen manche Anwendungen als Speicherplatz nicht, sondern sie erwarten "Block Storage" oder zumindest etwas, das wie lokales (Block) Storage aussieht. Das kann man unter Windows hinbekommen, indem man eine VHDX-Datei als virtuellen Datenträger verwendet. Kommt aus der Welt der Virtualisierung und ist in der Hyper-V-Welt quasi der "lokale Datenträger" für virtuellen Maschinen. Nun kann man netterweise eine solche VHDX-Datei auch auf eine SMB-Freigabe legen und die dann von und auf einem Client "lokal" einbinden. Für den Client und vor allem alle Anwendungen sieht das dann so aus, als wäre die VHDX-Datei ein lokaler Datenträger, obwohl sie hübsch auf unserem Server liegt.

iSCSI-Freigaben werden von Windows beim Booten wieder automatisch eingebunden, so dass man das Ganze einmal einrichtet und sich dann um eigentlich nichts mehr Gedanken machen muss. Nett. Eine ähnliche Funktion gibt es auch für SMB-Freigaben, wenn man diese als Netzlaufwerk verbindet: beim erstmaligen Verbinden fragt einen Windows ja, ob die Verbindung bei (je)der nächsten Anwendung wiederhergestellt werden soll. Auch nett. Leider bindet Windows VHDX-Dateien beim Booten oder Anmelden nicht automatisch wieder ein. Dafür muss man manuell einen Task anlegen - weitere Details habe ich dazu ja hier schon einmal festgehalten. Für reine Testzwecke brauchen wir das aber natürlich nicht.

Nochmal kurz zum Setup:
Server-Storage: Mirror aus 2x 1TB NVMe Samsung 980 Pro, ReFS (Standard-Settings, insb. Fileintegrity=FALSE - wir wollen mal max-speed sehen).

Kurzes Schaubild zum Setup:

1709645723668.png


0. Ein lokaler CrystalDiskMark (best-case-scenario) auf dem Server ergibt folgende Werte:
1709643463200.png


Wechseln wir nun zum Client, d.h. alle weiteren Benchmarks laufen in irgendeiner Form über's Netz auf dem Server-Storage:

1. iSCSI-Share, das logische Volume der Freigabe liegt auf dem gleichen Mirror wie oben unter Nr. 0:

1709643650502.png


2. SMB-Share, einfach ein freigegebener Ordner auf dem Volume von Nr. 0:

1709643715032.png


3. VHDX-Datei im freigegebenen Ordner auf dem Volume von Nr. 0:

1709643783757.png



Mein Eindruck:

1. Wir sehen eindrucksvoll, wie nah man mit RDMA auch über's Netz an die Performance von lokalem Storage herankommen kann. Nur 4K read und write mit niedriger Queue verliert prozentual gesehen deutlich. Bei den sequenziellen Lesewerten limitiert vermutlich schon meine 100gbit-Verbindung... :d

2. Ein wenig Anomalie gibt's auch: bei RND4KQ32 geht's über's Netz besser als lokal (vor allem write)...

3. iSCSI (in meinem Setup ohne RDMA) ist der klare Verlierer.

4. Die Leistungseinbuße zwischen SMB-Freigabe direkt und VHDX-File "darüber" ist vernachlässigbar. Gerade wenn der Server als zentraler Storage "für alles", insb. als unproblematischer Installationspfad für Anwendungen (Spiele) herhalten soll, ist die VHDX-Datei m.E. ein großer Vorteil.
Beitrag automatisch zusammengeführt:

Und weil ich neugierig bin, das Gleiche nochmal mit FileIntegrity=true:

0. Lokal:

1709645854459.png


1. iSCSI:

1709646020955.png


2. SMB-Freigabe (pur):

1709646310581.png


3. VHDX in SMB-Freigabe:

1709646797600.png


Irgendwie scheint das Verlangen von Checksummen unter ReFS bei den Netzwerkfreigaben keine Auswirkungen zu haben. Lokal wird's deutlich langsamer, die Zugriffe über's Netzwerk interessiert das aber herzlich wenig bis gar nicht (m.E. im Rahmen von Messtoleranzen). Auch eine Erkenntnis... ob ReFS das dann einfach bei Netz-Zugriffen nicht macht? Müsste man mal googlen... bin aber zu faul. Für mir liegen da eh nur unwichtige Dinge, die wichtigen liegen brav auf dem ZFS Storage-Server ohne solche Spielereien. ;)

Next:
Weiter mit VHDX über SMB testen, dann Clients umrüsten.
 
Zuletzt bearbeitet:
Ich bin platt, 11 GB/s übers Netz mit SMB
(Gigabyte/s nicht Gigabit/s).

Schafft man das auch mit aktuellem ZFS on Windows?
 
Zuletzt bearbeitet:
Schafft man im Zweifel schon nicht mehr bei einer 100GB-Datei im Copy-Job. Wobei mir gerade noch das flotte Storage auf der Gegenseite fehlt, die zwei Optane im Mirror reichen nicht. Aber Abhilfe für die nächsten Tests ist schon da…

Hier copy-job von lokal Optane-mirror auf NTFS-VHDX über's Netz:

1709667168873.png


Der lokale Optane-mirror kommt "nur" auf folgende Werte:

1709668351397.png


Deshalb ist für mich CDM auch im Endeffekt was absolute Performance angeht wirklich null aussagekräftig, sondern kann eben nur Unterschiede aufzeigen. Und selbst da muss man aufpassen, dass man auch immer die exakt gleiche CDM-Version erwischt, sonst kann's auch schon deutliche Unterschiede allein deshalb geben.
Beitrag automatisch zusammengeführt:

@gea: hier das Ganze mal per SMBdirect auf eine VHDX auf SMB-Share auf ZFS-mirror (wie immer: 2x NVMe):

1709668784733.png



1709668947352.png


Performance ist schon sichtbar schlechter. Die Kopiergeschwindigkeit ist fast immer unter 1GB/s, teils runter auf 300MB - das gab's mit ReFS nicht.
 
Zuletzt bearbeitet:
  • Danke
Reaktionen: gea
@besterino

Hast du in deinem esxi/Solaris eine ähnliche Windows VM als Server und auch den vergleichbare Storage/Nic darunter? Also im Grunde das typische Szenario eine Windows Dateiservers in einer Virtualisierungsumgebung, mit entsprechend großem Laufwerk D (vmdk, wie windows im solaris storage) was über smbdirect deine vhdx bereitstellt.

Dann könnte man mit Abzug eines Overheads sehen, was dabei herauskommt, wenn das ganze auf ZFS in der Geschmacksrichtung Solaris läuft.
 
Zuletzt bearbeitet:
Hab nun also mal das Storage beim Client zu Testzwecken aufgerüstet.

Lokal:

1709669924133.png


SMBdirect-ZFS-VHDX (lesend) --> lokal (schreibend) = ca. 1-1.2GB/s

1709670074112.png


lokal (lesen) --> SMBdirect-ZFS-VHDX (schreibend) = ca. 700MB/s

1709670674327.png



lokal (lesend) --> SMBdirect-ReFS-VHDX (schreibend) = ca. 1.5GB/s

1709670193874.png


SMBdirect-ReFS-VHDX (lesend) --> lokal (schreibend) = auch ca. 1.5GB/s

1709670488769.png


ZFS hängt schon hinterher.
Beitrag automatisch zusammengeführt:

@Luckysh0t: ich fahre gerade zu Testzwecken Solaris und Windows Server 2022 parallel als VM unter ESXi. Beide VMs haben je 4 NVMe SSD sowie mindestens einen 100Gbit-Port einer physischen NIC per Passthrough bekommen (die Windows-VM sogar beide Ports). Der Overhead durch ESXi dürfte dadurch minimal sein.

Eine VMDK macht da meines Erachtens wenig Sinn, wenn ich auf der Suche nach maximaler Performance bzw. Flaschenhälsen bin. Laufwerk C: von der Windows-VM ist allerdings eine VMDK, die auf'm NFS-Storage der Solaris-VM liegt. Noch Fragen oder soll ich's noch weiter Verschachteln? :d
 

Anhänge

  • 1709670578086.png
    1709670578086.png
    5,3 KB · Aufrufe: 53
Zuletzt bearbeitet:
  • Danke
Reaktionen: gea
erster Eindruck:
ReFS on Windows ist nicht so schlecht wie oft berichtet (zumindest im Basis Setup, mit großen Arrays müsste man das noch verifizieren)
ZFS on Windows ist ausreichend schnell für die meisten Anwendungen, mit Potential nach oben
 
Für große Arrays fehlt mir jedenfalls das Kleingeld. Und der Platz. Und die Klimaanlage. Und die Schallisolierung. :d

Mich nervt aber gerade noch, dass ich bei 'nem simplen Copy-Job von so 100GB über's Netz nie wirklich über 2GB/s hinaus komme. Werde das mal die Tage nochmal lokal gegentesten. Die SSDs selbst müssten locker für mehr gut sein. Und das Netz auch. (Wenn das lokal auch nicht klappt, schreibe ich in Zukunft unter jedes SSD-Review, dass die sich ihre Tests mit all den tollen Benchmarktools gerne entspannt in die Haare schmieren oder sonstwohin stecken dürfen.

Da fällt mir nochwas ein: die ZFS-Tests oben sind mit sync=disabled gelaufen.
 
Ich bin es gewohnt mit SMB single user bei 300-500 MB/s zu landen. Das ist eigentlich zu wenig für 4k Video Editing. Mit Tuning und Jumbo gehen dann eventuell 800 MB/s auch mit Netz > 10G. Weit weg von den 2GB/s zumal bei der niedrigen CPU Last enorme Reserven für Multi-User da sind. Ein User könnte auch statt mit NAS auch mit DAS arbeiten, ohne den Aufwand. Ab vielleicht 1GB/s für mehrere gleichzeitige Nutzer wird es spannend mit zentralem High Performance Storage. Und das ist es ja wofür man großes ZFS Storage möchte.
 
Zuletzt bearbeitet:
Ja leck' mich doch am...

Ich hab jetzt von einem Raid0 auf ein anderes Raid0 mit je 2x Lexar NM790 4TB lokal kopiert und komme da beim Copy-Job auf ziemlich konstante ~2.1GB/s.

1709759553156.png

Mehr geht also nicht.

Habe nun also mal testweise auch auf dem Server statt Mirror auf Stripe gewechselt und komme jetzt über's Netz nah an das "lokale Maximum" ran:

1709761339318.png


Freude: nicht das Netz ist der Flaschenhals, sondern immer noch/mal wieder das Storage rechts und/oder links von der Leitung.

Wir merken uns: Consumer NVMe-Storage ist in der Realität selbst im Raid0 immer noch zu lahm für 100gbit.​

RAMdisk in der Größe von 100GB? ... *grübel*
 

Anhänge

  • 1709761136514.png
    1709761136514.png
    4,7 KB · Aufrufe: 60
Consumer NVMe-Storage ist in der Realität selbst im Raid0 immer noch zu lahm für 100gbit.
Enterprise SSD mit der gleichen Schnittstelle dürften nicht viel schneller sein, sie halten die Geschwindigkeit aber dafür konstanter.

Ich würde eher davon ausgehen, dass zwei im RAID 0 zu langsam sind. Mit ein paar mehr würde das bestimmt anders aussehen, aber erstmal haben ^^
Beitrag automatisch zusammengeführt:

RAMdisk in der Größe von 100GB? ... *grübel*
Mit RDMA in eine RAMDisk ? Das wäre wirklich was ^^
 
Zuletzt bearbeitet:
Ramdisk => NVDIMM´s wären für so ein System mMn schon empfehlenswert.
 
Also ich hab jetzt mal nach dieser Anleitung eine RAMdisk erstellt (also über iSCSI aber "lokal"). Funktioniert sogar, aber die Ergebnisse sind ernüchternd, geradezu ein schlechter Witz:

1709850100093.png


Offenbar ist die Vergewaltigung über iSCSI von hinten durchs Knie nicht wirklich performant. Was ich im Netz dazu gefunden habe, sagt, dass 3rd-party-tools teilweise doppelt so schnell sind. Haha. Selbst doppelt so schnell ist immer noch Käse.

Na dann noch einmal Brechstange:
Server 4xNVMe 1TB Samsung 980 Pro im Stripe
Client 4xNVMe 4TB Lexar NM790 im Stripe

Lokal:

Server
1709852680341.png

Client

1709852662924.png



Über's Netz (immer aus Sicht des Client):

1709851838976.png


1709851899612.png


1709852768372.png


Alrighty then. Besser wird's wohl nicht mehr (mit der mir zur Verfügung stehenden Hardware, insbesondere Storage). Immerhin: Das Maximum, das ich im Explorer beim Kopieren über's Netz gesehen habe, waren 4.8GB/s. Mehr wird ohne Optimierung irgendwo wohl nicht gehen, aber zum "wie" fehlen mir gerade echt die Ideen/Ansätze...

Ernüchternd ist jedenfalls schon, wie wenig von diesen tollen Werbe-Angaben bei SSDs á la ">7000MB/s" in der Realität ankommt. Theoretisch sollte so ein 4er Stripe ja eigentlich irgendwo an den 30GB/s kratzen. Ha. Ha. Ha.
 

Anhänge

  • 1709851032033.png
    1709851032033.png
    12,1 KB · Aufrufe: 45
Zuletzt bearbeitet:
Ich denke, Windows wird hier absichtlich limitieren.
Gerüchteweise soll Storage unter Win11 inzwischen messbar schneller sein als unter Win10, welches ich nach wie vor nutze.
Capture.PNG
 
Wie/womit hattest Du denn bei dem CDM-run die RAMdisk aufgesetzt?
 
Wie/womit hattest Du denn bei dem CDM-run die RAMdisk aufgesetzt?
Mit einer kostenpflichtigen Software (PrimoCache), welche Schreibzugriffe von Volumes in den RAM umleiten kann, deswegen nur Quasi-RAM-Disk.
Außerdem hat dein Quad-Stripe Setup seq. höhere Werte produziert. Ist bei mir allerdings nur eine APU und RAM nicht hochgetaktet, was das vielleicht erklärt.

Im BIOS von meinem AsRock Rack Board habe ich eine RAM-Disk-Option gefunden, allerdings nie ausprobiert.
 
Zuletzt bearbeitet:
Hab mal wieder mit S2D und ReFS rumgespielt. Parity vs. mirror - wenn man Checksummen auf File-Ebene aktiviert, geht die Performance schon ziemlich in den Keller. Allerdings tun sich dann parity und mirror gar nicht mehr so viel - vielleicht noch bei 4K writes:

1712260312140.png

Beitrag automatisch zusammengeführt:

Lege ich auf dem Mirror aus den runs oben (vgl. oben rechts) dann eine VHDx mit NTFS ab und hänge die in einer VM ein, sieht das dann so aus:

1712261360926.png


Gar nicht mal soooo übel.
 
Zuletzt bearbeitet:
Und noch ein Vergleich: 2-SSD im Mirror einmal bare metal und einmal per DDA in einer VM. Bei allen Tests bisher verliere ich durchaus performance allein schon beim Durchreichen von NVMEs an eine VM, insb. wenn man sich die 4k Werte anschaut:

Der einzige Vergleich, der noch aussteht ist der Wechsel der jeweiligen Pärchen, also die derzeit an die VM durchgereichten auf bare-metal und vice versa. Um Hardware-Einfluss auszuschließen mache ich das auch nochmal bei Gelegenheit.

1712270874996.png
1712270954511.png
 
Was DDA betrifft, hab ich auch mal was gebencht.

Ein und dieselbe SSD in einer VM und auf dem Host, mit zwei verschiedenen Powerplänen.
CrystalDiskMark_20240405085544.png
CrystalDiskMark_20240405085402.png

CrystalDiskMark_20240405090301.png
CrystalDiskMark_20240405090436.png

Ich würde sagen, der PowerPlan macht den größten Unterschied.
 
Zuletzt bearbeitet:
Interessant, da hätte ich wohl gar nicht mit gespielt! Hab einfach sowohl Blech als auch in der VM nix angefasst. Filesystem bei Dir war NTFS?
 
Je mehr Info, desto besser kann man das einordnen. :)
 
Für die manuelle Partitionierung eines Windows-OS Datenträgers bzw. VHD(x), liefert MS jetzt sogar selbst die Scripts (sogar in verschiedenen Geschmacksrichtungen):


Die kann man dann z.B. auf einen USB-Stick packen und über ein Windows Install-Medium (Shift+F10) aufrufen und mit 2 weiteren Befehlen Windows 11 auch auf nicht mehr unterstützten Plattformen installieren.

Bin ziemlich begeistert, das kann man immer mal brauchen.

Zu Erinnung (auch für mich selbst), wie man per cmd ein Windows installiert, hab ich hier mal festgehalten:

 
Außerdem geht Windows von sich aus immer über die lahmere 1Gb-Verbindung, ich musste tatsächlich das Kabel ziehen, damit 5Gb genutzt wird. 🤬
In dem Fall sollte man sich über die IP-ADRESSE verbinden, oder die Metrik entsprechend einstellen, um die Priorität der Schnittstellen einzustellen
 
In dem Fall sollte man sich über die IP-ADRESSE verbinden, oder die Metrik entsprechend einstellen, um die Priorität der Schnittstellen einzustellen
Bringt alles nichts, SMB geht eigene Wege.
Screenshot 2024-06-27 084655.png
Für mich ist das Verhalten von Windows nicht neu, aber tatsächlich gerade ein Problem. Ich wüste aktuell nicht, was ich dagegen tun könnte. Mit meinem Laptop hatte ich das Problem auch schon, aber dort tritt das Problem aktuell nicht auf (mit einer 2.5 Gbit USB3 Direktverbindung).
 
Zuletzt bearbeitet:
Moment mal... Wenn ich mich mit meinem TNS-Filer direkt über die 10GBIT IP-Adresse verbinde, dann gibt es keinen anderen Weg für die Daten :unsure:
 
Moment mal... Wenn ich mich mit meinem TNS-Filer direkt über die 10GBIT IP-Adresse verbinde, dann gibt es keinen anderen Weg für die Daten :unsure:
Nope, da liegst Du falsch, zumindest wenn wir von Windows SMB sprechen. Beispiel: Selbst wenn ich oben im Dateipfad des Explorers die gewünschte IP-Adresse stehen habe, interessiert das Windows beim anschließenden Copy nicht die Bohne.
PS: hab einen Mod gebeten, die Beiträge in den Hyper-V-Sammler zu verschieben... Ich entschuldige mich für OT. 😉
 
Zuletzt bearbeitet:
Korrekt. Das Phänomen hab ich auch schon beobachten müssen. 100Gbit liegen an aber Win11 nimmt für SMB-Transfers die 1Gbit Verbindung. SEHR sinnvoll…
Hatte dann keine Lust weiter rumzufrickeln. Evtl. hilft es ja schon, SMB-Multichannel zu deaktivieren und dann über die IP zu gehen…? IP allein reicht jedenfalls nicht.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh