Windows Server 2025: Native NVMe Delivers Major IOPS Gains

Microsoft has quietly flipped a fundamental switch in its server storage architecture: Windows Server 2025 now includes an opt‑in Native NVMe storage stack that removes the long-standing SCSI translation layer, promising dramatic IOPS uplifts and substantial CPU savings for modern NVMe SSDs — but with caveats that make careful validation and staged rollouts essential for production environments.

Background / Overview​

For decades, Windows presented block storage to the OS and applications using abstractions rooted in the SCSI model — an approach that preserved broad compatibility with spinning disks and early SSDs but did not match the parallelism and low latency NVMe was designed for. NVMe brings a massively parallel, multi‑queue submission/completion model (tens of thousands of queues and commands), while SCSI-style translation forces an inherently more serialized path through the kernel. The result: unnecessary CPU overhead, lock contention, and a software stack that could not keep up with modern PCIe Gen4/Gen5 SSDs and NVMe fabric solutions. Microsoft’s Native NVMe initiative rewrites that narrative by offering a storage path that speaks NVMe natively — eliminating translation, exposing multi‑queue capabilities, and streamlining kernel I/O work. Microsoft positions this as a core modernization of the Windows Server storage stack intended to let enterprise NVMe hardware reach its design limits.

---

What Microsoft announced (the essentials)​

• Native NVMe support is available in Windows Server 2025 and is delivered as part of servicing (included in an October cumulative update for WS2025). The feature is opt‑in (disabled by default) and requires administrators to enable it after applying the cumulative update.
• Microsoft’s lab numbers show up to ~80% higher IOPS on specific 4K random read workloads and roughly ~45% reduction in CPU cycles per I/O compared to Windows Server 2022 in the cited test cases. Those tests used DiskSpd.exe on a dual‑socket host with 208 logical processors and a Solidigm SB5PH27X038T NVMe SSD; Microsoft published the DiskSpd command line so others can reproduce the microbenchmarks.
• The company highlights practical benefits across SQL Server, Hyper‑V (faster VM boots and checkpoints), file servers, and AI/ML scratch workloads — workloads where IOPS, latency, and CPU per‑IO cost directly impact throughput and density.
• Microsoft’s announcement was quickly picked up across the tech press; independent writeups and community posts reproduced the core numbers and flagged the opt‑in nature plus the need for vendor‑driver validation.

---

Why this matters technically​

• Queue model alignment: NVMe was designed for flash and massively parallel I/O; Native NVMe lets the OS exploit the device’s native queueing and submission semantics instead of funneling commands through a SCSI‑oriented layer.
• Lower per‑IO CPU cost: The redesigned I/O path reduces kernel locking and context‑switch overhead, freeing CPU cycles for application work — a tangible advantage where storage I/O used to consume significant host CPU.
• Reduced latency and improved tail behavior: By removing translation and unnecessary synchronization points, per‑op latency drops and tail‑latency improves — important for OLTP databases and interactive VM workloads.
• Future extensibility: A native stack better exposes advanced NVMe features (multi‑namespace, direct submission paths, and vendor extensions) and lays groundwork for NVMe‑centric enhancements in the future.

---

Verifying the performance claims — what the numbers actually mean​

Microsoft’s published figures are compelling: lab tests reported up to ~80% higher IOPS (DiskSpd 4K random read) and ~45% fewer CPU cycles per I/O in selected configurations. These numbers are reproducible only under the documented test conditions — which are specific and optimized for microbenchmarking (enterprise NVMe device, high concurrency, NTFS volume, a particular workload profile). The DiskSpd command and hardware list were supplied by Microsoft to allow replication. Independent coverage reproduced and contextualized those results, reporting uplift ranges that vary by test methodology and hardware — most outlets and community threads report uplift ranges between roughly 60% and up to 80% depending on device, firmware, and queuing. That spread is expected: NVMe performance is tightly coupled to firmware behavior, PCIe generation, controller implementation, and driver choices. Important points to remember when interpreting the numbers:

• These are relative improvements versus Windows Server 2022 under specific microbenchmarks, not guaranteed application‑level improvements across all workloads.
• Vendor drivers or vendor‑specific firmware behaviors may produce different results than the in‑box Microsoft NVMe driver (StorNVMe.sys). Microsoft explicitly calls out that gains will only appear when using the Windows NVMe stack — some vendor drivers already implement their own optimizations and may not benefit.
• Real‑world benefits for databases, VMs, or file workloads depend on workload mix (read/write ratio), IO size, concurrency, and whether the storage is local or part of Storage Spaces Direct / NVMe over Fabrics.

---

Risks, stability concerns and why staged validation matters​

Large cumulative updates that change kernel I/O behavior can and have produced collateral issues. The October servicing package that delivered Native NVMe changes also contained unrelated fixes and regressions that Microsoft had to follow up on; community threads documented issues such as WinRE USB device problems and some HTTP.sys regressions tied to the October update stream. That underlines the importance of lab validation and careful rollout.
Additional risk vectors:

• Driver incompatibilities: Vendor NVMe drivers, third‑party HBAs, or storage fabric adapters may not interact correctly with the new stack in all firmware/driver combinations.
• Unverified enablement steps: Community posts circulated registry keys and Group Policy MSI names purporting to toggle Native NVMe; while Microsoft’s Tech Community post includes an enablement command for the feature in its guidance, other official KB pages and product docs may lag, and some community‑sourced toggles are unverified. Treat registry changes that modify kernel behavior with extreme caution and prefer documented vendor procedures.
• Clustered storage and failover behavior: For Storage Spaces Direct (S2D) and clustered deployments, the interaction of new NVMe paths with replication, resync, and repair flows must be validated under failure and recovery scenarios.

---

How to test and enable Native NVMe safely (recommended process)​

Microsoft’s Tech Community post lists a basic enablement process and a DiskSpd command for reproducing the microbenchmarks. Use the following as a validated, conservative roll‑out template rather than a checklist to change production systems without testing.

• Inventory and baseline
• Record NVMe model, firmware, vendor driver, and current OS build on each server.
• Capture baseline application‑level and microbenchmark metrics (IOPS, avg/p99 latency, host CPU utilization, disk transfers/sec). Use DiskSpd, fio, and application metrics for a comprehensive baseline.
• Update firmware & drivers
• Update NVMe firmware and vendor drivers to the latest supported versions. Some vendors ship their own optimized drivers; compare Microsoft’s in‑box driver vs vendor driver during testing.
• Apply servicing to lab nodes
• Install the October LCU (KB5066835) or the most recent servicing package that contains the Native NVMe components on isolated lab machines. Do not mix unrelated enterprise LCUs until validated.
• Enable Native NVMe in a controlled environment
• Follow Microsoft’s documented enablement path from the Tech Community post (the post includes a registry/PowerShell command to enable the feature). Reproduce Microsoft’s DiskSpd microbenchmark parameters to compare results. Do not apply undocumented registry tweaks gleaned from third‑party forums without vendor confirmation.
• Validate real‑world workloads and cluster behaviors
• For Storage Spaces Direct and clustered roles, test resync, failover, live migration, and storage replication performance and correctness under load and during node failures.
• Staged rollout and monitoring
• Expand to a canary group, then ring out slowly to production with ongoing telemetry collection and a validated rollback plan.
• Keep an eye on Microsoft release notes and vendor advisories
• Follow Windows Release Health, device vendor advisory pages, and driver firmware notes for updates or hotfixes related to KB5066835 and subsequent servicing.

---

The exact enablement command Microsoft published (recreate the microbenchmark)​

Microsoft published a DiskSpd reproducible command line and an example PowerShell/registry command to enable Native NVMe after applying the cumulative update. Administrators should use those documented steps only after validating in lab and ensuring full backups and rollback plans are in place. The DiskSpd command that Microsoft shared is usable for microbenchmarking and was published alongside the announcement to allow reproducibility. (Note: the Tech Community post includes the specific DiskSpd command line and the registry PowerShell sample; rely on the original Microsoft text when reproducing tests and follow change control policies before applying to production.

---

Real‑world impact: who benefits most?​

• Database servers (OLTP): Lower per‑IO CPU cost and reduced tail latency typically translate to improved transactions per second and lower response time for read‑heavy and mixed workloads.
• Virtualization hosts (Hyper‑V): Faster VM boot and checkpoint operations, plus reduced storage CPU overhead, allow greater VM density and smoother host consolidation.
• High‑performance file servers: Metadata operations and large sequential transfers benefit from lower latencies and higher IOPS headroom.
• AI/ML and analytics: Local NVMe scratch and datasets see reduced I/O latency and freed CPU cycles for computation rather than storage handling.

However, environments that rely on vendor‑specific drivers or have older NVMe firmware may see smaller gains or need vendor updates to fully benefit.

---

Windows 11: when will regular Windows clients get Native NVMe?​

Microsoft’s server announcement and codebase changes raise the obvious question: when does Native NVMe come to Windows 11? The short answer: Microsoft has not committed to a client timeline for the exact same native NVMe stack — the server update is explicitly packaged for Windows Server 2025 and released via server servicing channels. Community questions were asked directly in Microsoft’s Tech Community thread asking when Windows 11 Pro will see a similar change, and Microsoft responders acknowledged interest but did not publish a client rollout plan at the time of the announcement. Because Windows Server and Windows 11 share much of the kernel and storage codebase, a pathway for porting server NVMe improvements to client SKUs is plausible — but no public, vendor‑backed deployment date for Windows 11 was provided at the time of Microsoft’s announcement. Treat Windows 11 adoption of this feature as possible but unconfirmed. From a practical standpoint for gamers and consumer power users:

• Lowered CPU utilisation from storage I/O would be helpful for CPU‑bound scenarios and heavy IO workloads (game installs, streaming asset loads), but Windows 11 users should not assume immediate availability. When/if Microsoft decides to release the same capabilities for client SKUs, it will likely follow an evaluation of stability in server environments plus internal policy about feature parity across channels.

---

Balanced technical analysis — strengths and cautionary notes​

Strengths

• Substantive architectural modernization: This changes how Windows treats flash media at the kernel level, removing long‑standing constraints.
• Meaningful performance and efficiency gains: The lab numbers and independent reporting show significant headroom for modern NVMe devices to perform closer to their hardware limits.
• Future‑proofing: The native stack enables deeper support for advanced NVMe features and better scaling for Gen4/Gen5/Gen6 hardware.

Risks and trade‑offs

• Compatibility surface area: The opt‑in model indicates Microsoft’s caution — many environments will need vendor driver/firmware updates and full validation before broad enablement.
• Servicing complexity: Shipping the change inside a large cumulative update introduces the risk of unrelated regressions; history shows that major LCUs can have side effects that require follow‑up fixes.
• Variable real‑world uplift: The headline ~80% IOPS is a synthetic result under a specific test harness; administrators should expect a spectrum of gains depending on workload and hardware.

Unverifiable or evolving claims

• Some community posts and aggregated articles reported registry keys and toggle methods that could not be verified against Microsoft’s primary KB pages at the time of review; those should be treated as unverified and avoided without vendor confirmation. Use Microsoft’s Tech Community guidance and official KB notes as the authoritative source.

---

Practical checklist for IT teams (quick)​

• Inventory NVMe devices, firmware, and driver stacks.
• Apply KB5066835 (or later LCU that includes Native NVMe) to lab nodes only.
• Reproduce Microsoft’s DiskSpd microbenchmarks then run representative application tests (DB TPS, VM boot storms, file server metadata operations).
• Validate S2D and cluster failover/resync behavior under stress.
• Use staged rollouts with telemetry and a rollback path.
• Avoid undocumented registry tweaks in production; follow vendor guidance.

---

Conclusion​

Microsoft’s Native NVMe support in Windows Server 2025 is a significant step in aligning the Windows storage stack with modern flash hardware. The change promises large efficiency and performance gains — up to ~80% IOPS in Microsoft’s lab tests and meaningful CPU cycle reductions — but those headline numbers are conditional on specific hardware, firmware, and workload profiles. The opt‑in nature of the rollout, combined with documented side‑effects in the servicing channel, makes measured validation, vendor coordination, and staged deployment the prudent path forward for enterprises.
For now, server operators with NVMe fleets should prepare lab validation projects: update firmware/drivers, apply the servicing packages in controlled rings, and measure both microbenchmarks and real‑world application behavior before enabling Native NVMe broadly. Windows 11 users and gamers may benefit in time, but Microsoft has not published a client delivery timeline — the feature remains a server‑first modernization until further notice.

---

---

Source: OC3D When Windows 11? Microsoft boosts Windows Server with Native NVMe support

 

[ChatGPT]

Microsoft’s engineers have quietly removed a long-standing software choke point for NVMe storage—and the result is one of the most consequential storage improvements in Windows Server in years: a native NVMe I/O path in Windows Server 2025 that can deliver radically lower per‑I/O CPU cost and major IOPS gains for modern NVMe SSDs, and which adventurous users are already experimenting with on Windows 11 despite it being officially server‑only.

Background / Overview​

For decades Windows exposed block storage through an I/O model rooted in SCSI semantics. That design made sense for spinning disks and early SATA SSDs, but it increasingly became a software bottleneck as NVMe hardware brought massively parallel queues and very low latency. NVMe is architected for thousands of submission/completion queues and very deep queue depths; translating NVMe semantics into a SCSI-style model introduces serialization, extra context switches, and CPU overhead that can prevent drives from reaching their hardware limits. Microsoft’s new native NVMe path removes that translation for supported server installations and exposes NVMe semantics directly to the kernel. This is both a technical modernization and a practical one: Microsoft’s published lab microbenchmarks show very large uplifts on some enterprise hardware—up to ≈80% higher IOPS and ≈45% fewer CPU cycles per I/O on the workloads they measured—while community testing on consumer systems shows smaller but still meaningful gains in many cases.

---

What changed under the hood: SCSI emulation vs native NVMe​

Why Windows historically used a SCSI path​

Windows' historical approach favored a uniform block device abstraction that made device management and compatibility simpler across HDDs, SATA SSDs, SANs, and NVMe devices. That meant Windows often converted NVMe commands to SCSI equivalents via the StorNVMe translation support layer—useful for interoperability, but increasingly inefficient as NVMe evolved. The StorNVMe translation table and design is documented in Microsoft’s driver documentation and explains which SCSI commands map to NVMe commands.

What “native NVMe” actually does​

The native NVMe path eliminates the per‑I/O SCSI‑translation step and reworks the kernel I/O plumbing to:

• Expose NVMe’s multi‑queue semantics (per‑core queues and high concurrency).
• Reduce kernel locking and serialization points that add CPU overhead and tail latency.
• Allow submission/completion behavior to use lock‑free or per‑core structures more aligned with NVMe hardware.

In plain terms: Windows speaks NVMe directly instead of pretending every storage device is SCSI and translating. That unlocks far more efficient use of modern NVMe controllers and their very high IOPS ceilings.

---

The official Microsoft story and the exact enablement path (Server)​

Microsoft shipped Native NVMe as an opt‑in feature in Windows Server 2025, delivered through its servicing cadence and disabled by default. Administrators are instructed to:

• Confirm the NVMe SSDs are using the in‑box Windows NVMe driver (devices using vendor‑specific drivers will generally not see benefit).
• Apply the relevant cumulative servicing update (the company referenced “the 2510‑B Latest Cumulative Update” / October servicing wave as the delivery mechanism).
• Enable the feature via a documented Feature Management override (registry) or Group Policy/MSI method.

Microsoft published the reproducible microbenchmark parameters (DiskSpd) and the recommended registry toggle. The canonical registry command Microsoft documented is:
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides /v 1176759950 /t REG_DWORD /d 1 /f
Microsoft’s post explicitly warns the feature is disabled by default and should be enabled after administrators stage updates and validate behavior.

---

How enthusiasts are experimenting on Windows 11 (and why you should be cautious)​

Because the kernel components are shared across Windows Server and Client SKUs, enterprising community members discovered that similar Feature Management overrides can flip the native NVMe path on recent Windows 11 builds (24H2/25H2). Community threads and forum posts document various override values and methods some testers used to enable the driver on consumer platforms; results range from modest single‑digit to mid‑teens percentage improvements to spectacular gains on a few hardware+firmware combinations. Important caveats:

• This is unsupported on Windows 11: Microsoft’s official guidance covers Server only. If you enable experimental flags on client SKUs you accept stability, driver, and boot risks.
• Vendor drivers can block benefits: NVMe devices using vendor‑supplied drivers (Samsung, SK hynix, Samsung NVMe drivers, Intel/Solidigm vendor drivers, etc. may not switch to the Windows in‑box path or may behave unpredictably.
• Some testers reported drive detection issues, Device Manager differences, or incompatibilities with backup/imaging tools after switching the driver stack; others reported boot failures in isolated cases. Community threads document both successes and failures. Back up before you experiment.

For administrators and power users who want to test on client hardware, the safest route is to use a non‑production test device or a VM (where possible) and to ensure you have a reliable offline recovery/boot media and image restore plan.

---

Benchmarks: Microsoft’s lab numbers and what they mean​

Microsoft’s lab tests focused on small‑block, high‑parallelism workloads (4K random I/O), which best expose kernel overheads. Their published DiskSpd command is:
diskspd.exe -b4k -r -Su -t8 -L -o32 -W10 -d30
On a high‑end dual‑socket testbed (208 logical processors, 128 GB RAM) with an enterprise Solidigm NVMe SSD, Microsoft reported up to ~80% higher IOPS in that synthetic workload and ~45% fewer CPU cycles per I/O compared with the legacy SCSI-based path. These are lab microbenchmarks designed to show the headroom removal; Microsoft supplied the command so others can reproduce the synthetic runs. Independent press and community testing show the typical pattern you should expect:

• Enterprise servers with high‑end Gen4/Gen5 SSDs and highly concurrent workloads see the largest benefits (tens of percent to multiples).
• Consumer/laptop systems commonly show smaller but still useful gains — many reports cluster in the single‑digit to mid‑teens percent improvement range for mixed desktop workloads, though extreme cases produced >50% improvements in particular synthetic tests.

Reality check: synthetic microbenchmarks are valuable for understanding kernel overhead differences, but they do not automatically translate to identical application‑level improvements. Real workloads have different IO sizes, concurrency, and bottlenecks. If the system’s bottleneck is CPU, network, or application threading rather than the kernel’s storage path, you may see minimal user‑visible change.

---

How to test safely and meaningfully (step‑by‑step testing checklist)​

• Inventory and baseline
• Record SSD make/model, firmware, and current driver (Windows in‑box vs vendor).
• Capture baseline performance: IOPS, throughput, P50/P95/P99 latency, CPU usage, and Disk Transfers/sec.
• Update firmware and platform drivers
• Update SSD firmware, motherboard BIOS/UEFI, and any storage‑related firmware before toggling the feature.
• Apply the server servicing update (Server path)
• For Server: apply the cumulative update containing Native NVMe, then enable the documented Feature Management override.
• For client testing: consider using a disposable test image or VM. Do not change production devices.
• Reproduce Microsoft’s DiskSpd microbenchmark (for raw kernel-oriented comparisons)
• Use the exact DiskSpd command Microsoft published and then run your real workload tests.
• Example command: diskspd.exe -b4k -r -Su -t8 -L -o32 -W10 -d30. Measure CPU cycles per I/O and tail percentiles in addition to throughput.
• Measure comprehensively
• Evaluate p50/p95/p99/p999 latency slices, not just average throughput.
• Monitor application behavior (DB transactions/sec, VM boot times, backup throughput).
• Revert plan
• Know how to remove the registry override offline (WinRE) and restore the previous image. Keep bootable recovery media ready.
• Stage rollouts (Server)
• If results are positive, stage a limited rollout with robust monitoring and vendor validation before wide deployment.

---

Recovery, rollback, and troubleshooting tips​

• If a disk stops appearing after toggling the native NVMe path, do not panic: a number of community reports show the issue is often recoverable by booting WinRE and reverting the registry key, or by restoring an image. Still, avoid doing this on a single critical machine.
• Tools that identify disks by driver class or vendor may behave differently (some users saw devices listed under different driver classes), so update monitoring and backup policies accordingly.
• Vendor drivers: if your NVMe SSD uses a vendor driver, you’ll likely need to switch to the Microsoft in‑box driver—or verify vendor support—before seeing any benefit. Device managers and OEM management tools may need updated versions to recognize disks correctly after the change.

---

Ecosystem implications: firmware, backup tools, and OEM validation​

This change exposes a broader reality: software stacks must evolve in step with hardware semantics. The benefits of Native NVMe will be maximized when the whole ecosystem cooperates:

• SSD vendors should test firmware against the native NVMe path and publish compatibility notes.
• OEMs and motherboard vendors need to validate NVMe controller behavior under the new kernel path and update BIOS/UEFI where necessary.
• Backup, imaging, monitoring, and virtualization tool vendors must validate their products against the driver behavior changes to avoid unexpected identification or restore problems in production fleets.
• For enterprise customers, a coordinated validation matrix (firmware + BIOS + driver + OS toggle) is essential before mass deployment.

---

Recommendations: who should enable it and when​

• Server administrators running I/O‑bound workloads (OLTP databases, large virtualization hosts, high‑throughput file servers, AI/ML scratch nodes) should plan to test and stage Native NVMe in controlled lab environments. Follow Microsoft’s documented process, validate vendors’ guidance, and stage rollouts.
• Enthusiasts and power users: if you enjoy tinkering and can tolerate the risk, test on a non‑critical Windows 11 machine or VM to see whether your device/firmware yields gains. Back up and be prepared to recover.
• Ordinary desktop users should wait for Microsoft/OEM/vendor‑validated client support. Community hacks exist, but the potential for boot or backup issues means the risk often outweighs short-term gain for production machines.

---

What to expect in the near term​

• Microsoft has made the Server path official and reproducible; vendor validation and broader platform support will determine how quickly the native NVMe path becomes mainstream on client SKUs. The presence of the driver and kernel components in Windows 11 builds suggests a client rollout is feasible, but no formal client‑SKU support date has been published—so a cautious, staged approach remains best.
• Community tests will continue to surface real‑world variability. Expect modest gains on many consumer systems and dramatic gains on tuned enterprise platforms. Independent press coverage is already corroborating Microsoft’s core technical claim: the SCSI translation path used to be a bottleneck for NVMe.

---

Final verdict — strengths and risks​

Strengths

• Fundamental alignment of Windows I/O semantics with NVMe hardware unlocks real technical headroom.
• Measurable microbenchmark improvements in high‑parallelism workloads—Microsoft documented reproducible commands and tests.
• Potential for lower per‑I/O CPU cost, which matters for dense virtualization, AI scratch usage, and large database servers.

Risks

• Unsupported consumer experimentation can produce boot, backup, or tooling incompatibilities; do not enable experimental flags on production Windows 11 machines.
• Vendor drivers and firmware might not be immediately compatible; vendor validation is needed to ensure stable behavior.
• Numbers are configuration‑dependent: Microsoft’s headline IOPS gains were obtained on high‑end server hardware and synthetic workloads; real‑world gains will vary. Treat community claims as indicative but not guaranteed.

---

Quick reference: safe steps to try the Server path (summary)​

• Confirm NVMe devices use the Windows in‑box driver (StorNVMe / nvmedisk behavior).
• Apply the cumulative servicing update that includes Native NVMe (October servicing/2510‑B or later as documented by Microsoft).
• Enable Native NVMe via Microsoft’s official FeatureManagement override:
  reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides /v 1176759950 /t REG_DWORD /d 1 /f
• Reboot, verify Device Manager/driver class, and run your baseline DiskSpd test first, then your real workloads.

---

Microsoft’s native NVMe work is a crucial, overdue modernization of Windows’ storage stack. It’s technically sound, demonstrably effective in appropriate contexts, and likely to reshape how Windows servers make use of modern NVMe hardware. The practical rollout will require vendor cooperation, careful validation, and sensible staging. For administrators running I/O‑intensive workloads, the feature is worth a deliberate, measured evaluation today; for consumer users, the better path remains to wait for official client support or vendor‑certified drivers that explicitly adopt the native path.

---

Source: How-To Geek How to unlock the massive SSD boost Microsoft is saving for Server 2025