Windows Server nimmt NVMe endlich ernst – und die Storage-Leute trauen dem Braten noch nicht

Es gibt wenig Befriedigenderes in der Infrastruktur, als zuzusehen, wie eine alte Annahme von einem Benchmark eins auf die Mütze bekommt. Jahrelang trug Windows Server in Storage-Kreisen einen Ruf, der von "okay für bestimmte Workloads" bis "warum ist das immer noch so?" reichte. Linux bekam zuerst das coole Storage-Spielzeug. Linux bekam die sauberere NVMe-Story. Linux bekam den effizienten Netzwerk-Stack, das User-Space-Treiber-Ökosystem, die SPDK-Dynamik und generell das Gefühl: Wer sich für rohe Storage-Performance interessierte, wartete wohl kaum darauf, dass Microsoft die Parade anführt.

Dann taucht Windows Server 2025 in Benchmark-Form auf, mit nativen NVMe-Verbesserungen, Änderungen am Storage-Stack und Ergebnissen, die stark genug sind, um selbst manche abgehärtete Skeptiker innehalten zu lassen. Der ursprüngliche Beitrag verwies auf StorageReviews natives NVMe-Testing für Windows Server 2025, und die Diskussion wurde schnell zu etwas Größerem als nur einem Benchmark: Microsofts Storage-Stack, NVMe-oF-Frust, Linux-Vergleiche, Drittanbieter-Initiatoren, Windows' langfristige Zukunft und die Frage, ob irgendjemand bei klarem Verstand das schon in Produktion laufen lassen sollte.

Das ist der emotionale Kern hier. Die Leute wollen, dass Windows Server besser wird. Sie wollen nur nicht diejenigen sein, die es auf die harte Tour beweisen.

Der Benchmark war beeindruckend, aber Vertrauen lässt sich nicht sauber benchmarken

Die interessanteste Reaktion war keine blinde Feier. Es war Überraschung. Eine Stimme gab zu, ernsthaft beeindruckt zu sein, und sagte, es sei selten, dass jemand die Erwartungen so übertreffe. Man war auch überrascht, dass Windows im Folgevergleich Linux übertreffen konnte, weil Linux traditionell bei Storage- und Netzwerk-Effizienz die Nase vorn hatte. Das ist genau die Art von Aussage, die trifft, weil sie von genau der Sorte Mensch kommt, die Microsoft normalerweise keinen leichten Sieg gönnt.

Das ist wichtig. Storage-Leute sind nicht sentimental gegenüber Betriebssystemen. Sie interessieren sich für Latenz, Durchsatz, CPU-Effizienz, Kompatibilität, Observability und Ausfallverhalten. Wenn Windows echte Zahlen liefert, verdienen diese Zahlen Aufmerksamkeit. Eine Überarbeitung des Storage-Stacks, die tatsächlich die native NVMe-Performance verbessert, ist kein kosmetisches Detail. Sie legt nahe, dass Microsoft zumindest eine Ebene anfasst, von der viele Admins annahmen, sie sei vernachlässigt worden, während der Konzern Azure, KI und Abo-Umsätze jagte.

Aber Benchmarks sind nur der Anfang. Infrastruktur-Vertrauen wird unter hässlichen Bedingungen verdient, nicht in kontrollierten Tests. Was passiert nach Monaten im Dauerbetrieb? Was passiert über verschiedene Firmware-Versionen hinweg? Was passiert, wenn NIC-Treiber, Storage-Treiber, Multipathing, Failover und Hersteller-Targets alle in einem einzigen miesen Support-Fall aufeinandertreffen? Was passiert, wenn das System an einem Dienstag gepatcht wird und die Storage-Latenz plötzlich spukt?

Deshalb konnten manche die Ergebnisse bewundern und sich trotzdem weigern, überstürzt loszulegen. Ein Kommentator sagte, selbst wenn das Feature bald käme, würde er mindestens ein Jahr warten, bevor er einen Produktionseinsatz erwägt, weil er lieber andere Leute für Microsoft in Produktion betatesten lassen wolle. Das ist keine Feigheit. Das ist Überlebensinstinkt.

NVMe-oF ist das fehlende Puzzleteil, über das alle schimpfen

Der lauteste Frust im Thread drehte sich um NVMe-oF. Ein Kommentator meinte, man solle ihn anrufen, sobald Microsoft es endlich für NVMe-oF hinbekomme und der Storage-Stack "im aktuellen Jahrzehnt ankomme". Diese Zeile hat Biss, weil NVMe over Fabrics seit Jahren keine obskure Zukunftsidee mehr ist. In High-Performance-Storage-Umgebungen gehört es zum modernen Standard. Wenn Windows im ernsthaften Storage-Umfeld relevant bleiben will, sind native NVMe-Geräte nur ein Teil der Geschichte. Fabric-Konnektivität zählt.

Die Antwort darauf war differenzierter. Jemand sagte, das Gerüchteregal deute darauf hin, dass NVMe-oF vielleicht im Herbst kommen könnte, warnte aber davor, das als gegeben hinzunehmen. Dann kam die tiefergehende Kritik: Windows fehlt ein richtiger Polling-Modus, es fehlen interrupt-lose Operationen und User-Mode-Storage-Treiber der Art, die High-Performance-Storage-Stacks anderswo effizient machen. Deshalb wurde SPDK unter Windows quasi als Witz beschrieben, bei dem das Erreichen ähnlicher IOPS-Werte die CPU-Auslastung durch die Decke treibt.

Das ist die eigentliche technische Beschwerde. Es geht nicht einfach um "Microsoft ist spät dran". Es geht darum, dass Windows historisch bestimmte moderne Storage-Ansätze schwerer gemacht hat, als sie sein müssten. Die Linux-Welt war schon immer der natürlichere Ort für User-Space-Storage-Experimente, Kernel-Bypass und hocheffiziente Pfade. Windows kann durchaus schnell vorankommen, wenn Microsoft es ernst genug meint. Aber im Storage-Bereich haben viele Ingenieure das Gefühl, dass die Plattform einen schweren Legacy-Karren hinter sich herzieht.

Es gab auch einen praktischen Blick auf Drittanbieter. Ein Kommentator schlug vor, den StarWind-NVMe-oF-Initiator auszuprobieren, und sagte, er nutze ihn seit über sechs Jahren und könne damit doppelte 100-Gbit-NICs bei Sub-Millisekunden-Latenz auslasten. Eine andere Person antwortete, sie kenne das Tool, sei aber nicht sicher, ob sie die Kronjuwelen ihres Unternehmens darauf verlassen wolle. Dieser Austausch bringt das ganze Problem auf den Punkt. Drittanbieter-Tools können Lücken füllen. Sie können sogar gut performen. Aber wenn der Workload wichtig genug ist, fühlen sich native Unterstützung und Vertrauen auf Plattformebene anders an.

Niemand möchte, dass sich der wichtigste Datenpfad wie ein cleverer Workaround anfühlt.

Windows Server hat ein Glaubwürdigkeitsproblem, nicht nur ein Performance-Problem

Die brutalsten Kommentare drehten sich gar nicht wirklich um NVMe. Sie drehten sich um Windows Server als Produkt. Eine Person sagte, Windows sei frustrierend, weil es sich als Server-Betriebssystem rückständig und zäh in der Weiterentwicklung anfühle. Eine andere ging noch weiter und fragte, warum Microsoft überhaupt noch so tue, als entwickle man Windows aktiv weiter, und schlug vor, man solle zu einem Linux- oder BSD-Kernel wechseln und allen das Leid ersparen. Das ist hart, spiegelt aber jahrelang angestaute Verärgerung wider.

Der Gegenpunkt war pragmatisch. Microsoft hat immer noch eine riesige Basis an Firmenkunden, die von Windows abhängig sind. Würde der Konzern offen signalisieren, dass Windows keine Zukunft hat, würden Kunden mit dem Portemonnaie abstimmen und ihre Business-Apps zu Linux oder SaaS verlagern. Jemand verglich diese Art von Plattform-Unsicherheit mit den alten DEC-Alpha- oder Sun-SPARC-Momenten, wo der Exodus begann, sobald die Kunden die Schrift an der Wand sahen.

Deshalb hält Microsoft Windows in Bewegung, auch wenn Teile der technischen Community glauben, die Energie sei anderswo hingewandert. Windows ist nicht nur ein Betriebssystem. Es ist ein Ökosystem aus Anwendungskompatibilität, Unternehmensrichtlinien, Management-Tools, Authentifizierungsmustern, Hersteller-Support-Matrizen und Jahrzehnten an Business-Software. Man kann dieser Welt nicht einfach beiläufig sagen, sie solle weiterziehen.

Trotzdem hat die Kritik Gewicht. Mehrere Leute argumentierten, die eigentliche technische Schwerkraft innerhalb von Microsoft habe sich Richtung Azure und neuere Goldgräber-Bereiche verlagert, wodurch Windows Server unterversorgt wirke. Ein Kommentator behauptete, Leute mit Microsoft-Kontakten hätten gesagt, dass eine Zeit lang kaum noch ein echtes Kern-Windows-Team übrig geblieben sei, weil viele Leute entlassen, in Rente gegangen oder in Azure- und KI-Arbeit verschoben worden seien. Das mag eher Gerüchte-Niveau als belegte Tatsache sein, aber die Wahrnehmung zählt, weil Admins Plattformen zum Teil danach beurteilen, wohin sie die Aufmerksamkeit des Herstellers gerichtet sehen.

Ein Benchmark kann beweisen, dass sich ein Codepfad verbessert hat.

Er kann nicht sofort beweisen, dass Microsoft sich wieder kümmert.

Der Linux-Neid ist immer noch überall im Raum

Die Windows-versus-Linux-Debatte wurde schnell philosophisch. Eine Person argumentierte, die meisten Unternehmen verließen sich nicht so sehr auf den Windows-Kernel selbst wie auf Userland und die Hooks in den Kernel. Sie verwies auf Wine als Beleg dafür, dass eine Win32-Abstraktionsschicht funktionieren kann, und argumentierte, Microsoft habe bereits große Software wie SQL Server auf Linux portiert. Aus ihrer Sicht könnte Microsoft den Kernel fallen lassen, auf eine Abstraktionsschicht umsteigen und weitermachen.

Die Antwort darauf war bodenständiger. Wine-artige Kompatibilität funktioniert bei einfacheren Win32-Mustern, aber sobald Anwendungen stark auf Memory-Mapped-I/O, Completion Ports, APCs und andere zutiefst Windows-spezifische Verhaltensweisen setzen, wird es hässlich. Je "windowsiger" eine Anwendung wirklich ist, desto schwerer lässt sie sich zu Linux verschieben, ohne Performance oder Stabilität zu verlieren. Manchmal ist es leichter, neu zu schreiben, als das Ding hinüberzuschleppen.

Dieser Austausch trifft den Kern dessen, warum Windows Server überlebt. Die technische Szene mag von einer saubereren Linux-basierten Zukunft träumen, aber die Enterprise-Realität ist klebrig. Anwendungen sind eigenartig. Abhängigkeiten sind alt. Hersteller zertifizieren langsam. Interne Teams fürchten Migrationen mehr, als sie Ineffizienz hassen. Kompatibilität ist nicht elegant, aber sie ist mächtig.

Storage steckt in derselben Zwickmühle. Linux wirkt oft wie die Plattform, auf der moderne Storage-Ideen zuerst ankommen. Windows bleibt tief in Unternehmensumgebungen verankert, die weiterhin bessere Storage-Performance, bessere NVMe-Unterstützung und bessere Integration mit modernen Fabrics brauchen. Microsoft kann den Stack also nicht einfach aufgeben. Man muss ihn genug modernisieren, um Windows-Workloads glaubwürdig zu halten.

Deshalb zählen diese Benchmark-Ergebnisse. Sie legen nahe, dass Windows Server technisch immer noch überraschen kann.

Aber Überraschung ist nicht dasselbe wie Dominanz.

Die QA-Angst ist der eigentliche Produktions-Blocker

Der stärkste Grund, nicht in Produktion zu stürzen, war keine Ideologie. Es war QA-Angst. Ein Kommentator warnte, ein Jahr Wartezeit könnte sogar optimistisch sein, angesichts der wahrgenommenen mangelnden Qualitätssicherung bei Microsoft und des Verlusts von Leuten, die früher Plug-Tests, herstellerübergreifende Validierung und Interoperabilitätsarbeit übernommen hatten. Man verglich das mit der eigenen Erfahrung, seit etwa 2018 oder 2019 einen Drittanbieter-NVMe-oF-Initiator zu betreiben – der sei erst nach Jahren voller Kompatibilitätsprobleme über Targets, Treiber und NIC-Firmware hinweg wirklich brauchbar geworden.

Genau diese Art von Narbe nehmen Storage-Teams ernst. NVMe ist nicht mehr nur schnelles lokales Medium. Sobald Fabrics ins Spiel kommen, explodiert die Fehlermatrix. Initiatoren, Targets, NIC-Firmware, Switches, Treiber, Multipath-Verhalten, Timeout-Handling, Congestion, Firmware-Updates und Betriebssystem-Patches werden alle Teil der Geschichte. Ein Benchmark zeigt den Happy Path. Die Produktion zeigt, ob das Ökosystem schon Zahnspuren trägt.

Hier muss Microsoft mehr tun, als nur ein Feature auszuliefern. Man muss beweisen, dass sich das Feature über Hersteller und Updates hinweg vorhersehbar verhält. Das bedeutet Dokumentation, Zertifizierung, Referenzarchitekturen, klare Support-Grenzen und genug Praxis-Historie, damit Kunden sich nicht mehr wie unbezahlte Validierungslabore fühlen.

Storage-Admins haben gelernt, eine unspektakuläre Frage zu stellen: Wer hat das schon so oft schlecht laufen lassen, dass die Bugs gefunden wurden?

Bis es darauf eine gute Antwort gibt, gewinnt die Vorsicht.

Natives NVMe ist ein Anfang, aber die Storage-Welt ist längst weitergezogen

Die nativen NVMe-Verbesserungen in Windows Server 2025 sind wirklich bedeutsam. Lokale NVMe-Performance zählt für Datenbanken, Analytics, Hyper-V-Umgebungen, Edge-Workloads, Caching, Storage-Spaces-Szenarien und jedes System, bei dem latenzarmer lokaler Flash-Speicher das Anwendungsverhalten verändert. Ein saubererer, schnellerer Windows-Storage-Stack kann echten Kunden helfen.

Aber die Storage-Welt dreht sich längst nicht mehr nur um lokale Laufwerke. Moderne Infrastruktur handelt zunehmend von disaggregiertem Storage, Fabrics, gebündelter Performance, geteiltem Flash, Cloud-nahen Architekturen und Hochgeschwindigkeitsnetzwerken, die entfernten Storage für ernsthafte Workloads lokal genug wirken lassen. Daher rührt der NVMe-oF-Frust. Es ist kein reines Wunschlisten-Feature. Es ist ein Signal dafür, ob Windows Server in der nächsten Storage-Architektur vollwertig mitspielen kann.

Ein Kommentator wies darauf hin, dass Microsoft sein iSCSI-Target vor Jahren von String Bean Software übernommen hat, während der iSCSI-Initiator ursprünglich intern entwickelt wurde. Diese kleine Geschichtsstunde zählt, weil Windows schon früher sowohl auf interne als auch auf zugekaufte Bausteine gesetzt hat, um Storage-Lücken zu schließen. Die Frage ist jetzt, ob Microsoft moderne NVMe-oF-Unterstützung tief genug baut, um sich wie ein First-Class-Bürger anzufühlen, oder ob der Markt weiter auf Drittanbieter und Workarounds angewiesen bleibt.

Ein natives Feature kann die Wahrnehmung schnell ändern, wenn es funktioniert.

Ein halbgares natives Feature kann die Leute noch zynischer machen.

Das ist der schmale Grat, auf dem Microsoft wandelt.

Die seltsamste Reaktion war Optimismus

Unter all dem Spott steckte im Thread etwas fast Hoffnungsvolles. Leute scherzten über Bier-Care-Pakete, nachdem StorageReview mit Linux-gegen-Windows-Tests nachgelegt hatte. Der ursprüngliche Poster gab zu, beeindruckt und überrascht zu sein. Selbst manche Skeptiker klangen weniger danach, als wollten sie, dass Windows scheitert, sondern eher erschöpft davon, darauf zu warten, dass es aufholt.

Das ist wichtig. Der Frust der Storage-Community mit Windows ist nicht immer Hass. Es ist Enttäuschung. Windows ist überall. Es betreibt ernsthafte Workloads. Es sitzt in Unternehmen, die nicht alles zu Linux verlagern können oder wollen. Wenn Microsoft Storage besser macht, profitieren viele Leute.

Aber dieser Nutzen hängt von Vertrauen ab. Storage-Teams brauchen nicht, dass Microsoft jeden Benchmark gewinnt. Sie brauchen, dass Microsoft moderne Storage-Features ausliefert, die stabil, effizient, gut dokumentiert, supportet und in der Produktion langweilig sind. Langweilig ist hier das Kompliment. Langweilig heißt, niemand beobachtet, wie die CPU-Auslastung hochschießt, weil der Pfad ineffizient ist. Langweilig heißt, Firmware-Kombinationen werden nicht zur Archäologie. Langweilig heißt, NVMe-oF braucht keinen Forenthread, keinen Drittanbieter-Initiator und kein Stoßgebet.

Die nativen NVMe-Ergebnisse von Windows Server 2025 sind vielleicht das erste wirklich interessante Zeichen seit Langem, dass Microsoft den Storage-Stack noch voranbringen kann.

Der Applaus ist echt.

Genauso wie das Misstrauen.

Und im Enterprise-Storage hat das Misstrauen die letzte Stimme im Change-Control-Prozess.