• Guide, Sistemi Operativi
• 17 Agosto 2026

Le unità NVMe sono ormai utilizzate da diversi anni nei server e nelle workstation che richiedono prestazioni di storage elevate. Windows Server supporta questi dispositivi da tempo, ma fino a oggi le operazioni di I/O venivano gestite attraverso lo stack di archiviazione tradizionale di Windows, basato sui comandi SCSI.

Questo significa che i comandi NVMe dovevano essere tradotti in comandi SCSI prima di essere inviati al dispositivo. Un’architettura che ha garantito compatibilità e stabilità, ma che non permette di sfruttare completamente le caratteristiche delle moderne unità NVMe, progettate per gestire un elevato numero di code e operazioni parallele.

Con Native NVMe, Microsoft introduce in Windows Server 2025 un nuovo percorso di I/O che elimina questo livello di traduzione. Il driver Disk.sys viene sostituito da NVMeDisk.sys, mentre il nuovo componente StorMQ consente allo stack di storage di comunicare in maniera più diretta ed efficiente con il dispositivo.

Il risultato è una migliore scalabilità, con un possibile aumento degli IOPS, una riduzione della latenza e un minore utilizzo della CPU. I benefici effettivi dipendono naturalmente dall’hardware, dai driver e dal tipo di workload utilizzato.

La funzionalità è disponibile tramite aggiornamento cumulativo, ma al momento deve essere abilitata esplicitamente.

Prerequisiti

Per utilizzare Native NVMe è necessario disporre di Windows Server 2025 con l’aggiornamento cumulativo KB5066835, rilasciato il 14 ottobre 2025, o un aggiornamento successivo.

La build minima richiesta è la 26100.6899. È comunque consigliabile installare l’aggiornamento cumulativo più recente disponibile per Windows Server 2025.

Il computer deve inoltre utilizzare un dispositivo NVMe gestito dal driver Microsoft StorNVMe.sys. La presenza di un’unità NVMe, infatti, non garantisce automaticamente che sia possibile utilizzare il nuovo stack. Alcuni produttori forniscono driver proprietari per controller RAID, HBA o dispositivi NVMe che potrebbero non essere compatibili con questa modalità.

Il driver utilizzato può essere verificato da Gestione dispositivi, aprendo le proprietà del controller NVMe e selezionando la scheda Driver e quindi Dettagli driver. Nel caso venga utilizzato un driver fornito dal produttore, è consigliabile consultare preventivamente la relativa documentazione. Alcune soluzioni proprietarie potrebbero già comunicare direttamente con il dispositivo NVMe e, di conseguenza, non ottenere gli stessi benefici dal nuovo stack Microsoft.

Native NVMe è attualmente una funzionalità opt-in: l’installazione dell’aggiornamento non ne determina l’attivazione automatica. Prima di procedere è quindi consigliabile aggiornare il firmware delle unità e del controller, verificare la compatibilità delle applicazioni di gestione dello storage ed effettuare i primi test in un ambiente non di produzione.

Per maggiori informazioni è possibile consultare le pagine Microsoft dedicate all’aggiornamento KB5066835 per Windows Server 2025 e l’annuncio ufficiale di Native NVMe.

Abilitazione di Native NVMe tramite Registro di sistema

Prima di abilitare Native NVMe è opportuno verificare quale driver gestisce il controller. Aprite Gestione dispositivi, espandete la sezione Storage controllers e aprite le proprietà di Standard NVM Express Controller.

Nella scheda Driver verificate che il provider sia Microsoft, quindi selezionate Driver Details. Nel mio dispositivo viene utilizzato il seguente driver:

C:\Windows\System32\DRIVERS\stornvme.sys

Come si può vedere nella schermata, il controller utilizza StorNVMe.sys versione 10.0.26100.33296, firmato da Microsoft Windows. Si tratta del driver miniport NVMe incluso nel sistema operativo e richiesto per utilizzare il nuovo stack.

La presenza di stornvme.sys conferma che il controller utilizza il driver Microsoft, ma non indica che Native NVMe sia già attivo. StorNVMe viene infatti utilizzato anche dal percorso tradizionale, nel quale il disco è gestito dal driver di classe Disk.sys e visualizzato nella categoria Disk drives.

Se viene mostrato un driver fornito dal produttore del dispositivo o del controller, è consigliabile verificarne la compatibilità prima di procedere. I driver proprietari potrebbero utilizzare un percorso differente oppure offrire già specifiche ottimizzazioni per l’hardware NVMe.

Figura 1: Verifica del driver Microsoft StorNVMe.sys utilizzato dal controller NVMe

Come indicato da Microsoft, la funzionalità può essere abilitata creando uno specifico valore nel Registro di sistema. Prima di procedere è consigliabile effettuare un backup e provare la configurazione su un sistema non utilizzato in produzione.

Aprite Windows Terminal, PowerShell oppure il Prompt dei comandi con privilegi amministrativi ed eseguite il comando seguente:

Possiamo verificare la configurazione appena applicata con il comando:

Figura 2: Creazione e verifica del valore di Registro per l’attivazione di Native NVMe

La presenza della chiave non indica ancora che il nuovo stack sia in esecuzione. Per applicare la configurazione è necessario riavviare il sistema.

Dopo il riavvio possiamo verificare che Native NVMe sia effettivamente in esecuzione. Aprendo Gestione dispositivi viene visualizzata la nuova categoria Storage disks, all’interno della quale, nel mio caso, è presente l’unità Samsung SSD 960 PRO 1TB.

Il dispositivo Standard NVM Express Controller continua correttamente a essere presente nella sezione Storage controllers, perché il controller rimane gestito dal driver miniport stornvme.sys. A cambiare è il driver di classe utilizzato per gestire il disco.

Aprendo le proprietà dell’unità e selezionando Driver > Driver Details, tra i file caricati è ora presente: C:\Windows\System32\DRIVERS\nvmedisk.sys

Nel mio dispositivo vengono mostrati anche EhStorClass.sys e partmgr.sys, componenti Microsoft utilizzati rispettivamente dallo stack di archiviazione e dalla gestione delle partizioni.

La presenza di NVMeDisk.sys, insieme alla visualizzazione dell’unità nella categoria Storage disks, conferma che il sistema non sta più utilizzando il tradizionale driver di classe Disk.sys e che Native NVMe è stato attivato correttamente.

Figura 3: Verifica del caricamento di NVMeDisk.sys dopo l’attivazione di Native NVMe

Disattivazione di Native NVMe

Per tornare allo stack precedente è possibile eliminare il valore creato nel Registro di sistema eseguendo il comando seguente con privilegi amministrativi:

Anche in questo caso è necessario riavviare il sistema. Dopo il riavvio, l’unità tornerà nella categoria Disk drives e non utilizzerà più NVMeDisk.sys.

Prestazioni di Native NVMe

Secondo i test pubblicati da Microsoft, Native NVMe può offrire fino a circa l’80% di IOPS in più e un risparmio di circa il 45% dei cicli di CPU per ogni operazione di I/O rispetto allo stack utilizzato da Windows Server 2022, nel carico di lavoro misurato.

Il benchmark è stato eseguito con DiskSpd utilizzando letture casuali da 4 KB su un volume NTFS. Il sistema impiegato da Microsoft disponeva di due processori Intel, 208 processori logici, 128 GB di RAM e un’unità NVMe Solidigm SB5PH27X038T da 3,5 TB. Nella schermata pubblicata le prestazioni arrivano a circa 1,8 milioni di IOPS su Windows Server 2022 e a circa 3,3 milioni di IOPS su Windows Server 2025 con Native NVMe.

Figura 4: Incremento degli IOPS ottenuto da Microsoft con Native NVMe – Credits Microsoft

Questi valori non devono essere considerati come un risultato garantito. Il miglioramento dipende dal dispositivo NVMe, dal controller, dal numero di core disponibili, dalla profondità delle code e dal tipo di workload. I vantaggi diventano più evidenti nei sistemi che generano molte operazioni parallele e nei carichi caratterizzati da I/O casuale di piccole dimensioni.

Un aspetto particolarmente interessante riguarda l’utilizzo del processore. Lo stack tradizionale deve tradurre i comandi e gestire meccanismi di sincronizzazione condivisi. Native NVMe riduce queste operazioni e utilizza un percorso di I/O più diretto, consentendo di completare un numero maggiore di richieste con un minore numero di cicli CPU per I/O.

Non significa necessariamente che in Gestione attività la percentuale di utilizzo della CPU debba sempre diminuire. Il nuovo stack potrebbe utilizzare una percentuale simile del processore, ma completare molte più operazioni nello stesso intervallo di tempo. Per questo motivo è importante confrontare insieme IOPS, latenza e utilizzo della CPU.

Test delle prestazioni con DiskSpd

Per verificare le prestazioni possiamo utilizzare DiskSpd, lo strumento Microsoft per la generazione di carichi di lavoro sullo storage, disponibile nel repository ufficiale Microsoft.

Alla pagina Releases · microsoft/diskspd potete scaricare la versione più recente, attualmente DISKSPD 2.2. Nella sezione Assets scaricate il file DiskSpd.ZIP ed estrarla in una cartella a vostro piacimento.

Figura 5: Repository di DiskSpd, lo strumento Microsoft per la generazione di carichi di lavoro sullo storage

I test devono essere eseguiti su un volume dedicato e privo di dati importanti. È sconsigliato utilizzare il volume del sistema operativo oppure un disco impiegato da applicazioni in produzione, perché il benchmark genera un carico molto elevato.

Dopo aver scaricato DiskSpd, aprite una sessione amministrativa di PowerShell e create sul volume da analizzare un file di test sufficientemente grande. Nell’esempio utilizzerò il volume F: e un file da 20 GB:

Il parametro -b4K imposta operazioni da 4 KB, mentre -r genera accessi casuali. Con -Su viene esclusa la cache software di Windows, -t8 avvia otto thread e -o32 mantiene 32 richieste di I/O in attesa per ogni thread. Il test prevede 10 secondi di riscaldamento, indicati da -W10, seguiti da 30 secondi di misurazione tramite -d30. Il parametro -L abilita infine la raccolta delle statistiche sulla latenza.

Nel mio test DiskSpd ha completato 15.623.788 operazioni di lettura, raggiungendo una media di 520.753 IOPS e un throughput di 2.034,19 MiB/s. La latenza media rilevata è stata di 0,483 millisecondi.

Il carico è stato distribuito in modo uniforme tra gli otto thread, ognuno dei quali ha prodotto circa 65.000 IOPS. La sezione Write IO riporta valori pari a zero, confermando che il test ha generato esclusivamente operazioni di lettura.

Durante il benchmark l’utilizzo medio della CPU è stato del 57,38%, composto principalmente da tempo kernel. Questo comportamento è normale per un test di storage ad alta intensità, perché una parte significativa del lavoro viene eseguita all’interno dello stack di I/O del sistema operativo..

Figura 6: Risultati del test di lettura casuale da 4 KB eseguito con DiskSpd

Il singolo risultato mostra le prestazioni ottenute nella configurazione corrente, ma non è sufficiente per quantificare il beneficio di Native NVMe. Per effettuare un confronto attendibile è necessario eseguire lo stesso comando prima e dopo l’attivazione, mantenendo invariati file di test, parametri, profilo energetico e carichi in esecuzione.

È inoltre consigliabile ripetere il benchmark almeno tre volte e confrontare la media di IOPS, throughput e latenza. La percentuale di utilizzo della CPU fornisce un’indicazione generale, ma non corrisponde direttamente ai cicli CPU per I/O utilizzati da Microsoft nel proprio confronto.

Conclusioni

Native NVMe rappresenta un’importante evoluzione dello stack di archiviazione di Windows Server 2025. L’eliminazione della traduzione SCSI permette di sfruttare meglio il parallelismo dei dispositivi NVMe, con un possibile aumento degli IOPS, una riduzione della latenza e un utilizzo più efficiente della CPU.

I risultati dipendono dall’hardware, dal driver e dal carico di lavoro. Poiché la funzionalità è ancora opt-in, prima di adottarla in produzione è opportuno verificare firmware, strumenti di gestione, software di backup e procedure di ripristino, effettuando test comparativi su sistemi non critici.