Microsoft presenta WSL Containers: cosa cambia per Linux su Windows

Microsoft ha portato in anteprima pubblica WSL Containers (WSLC), una nuova estensione di WSL (Windows Subsystem for Linux) che permette di creare, eseguire e amministrare container Linux direttamente da Windows 11, senza appoggiarsi necessariamente a un ambiente container esterno. La novità arriva con WSL 2.9.3, pacchetto pubblicato a fine giugno 2026 come pre-release, e introduce il comando wslc insieme a un’API pensata per integrare i container Linux anche dentro applicazioni Windows native.

Facciamo in due parole la storia di WSL descrivendone la parabola ascendente: la prima versione nacque come livello di compatibilità al fine di eseguire binari Linux ELF su Windows; WSL 2, annunciato nel 2019, cambiò approccio usando un vero kernel Linux dentro una macchina virtuale leggera basata su Hyper-V. Da quel momento Windows è diventato un ambiente molto più credibile per sviluppatori web, cloud, DevOps e AI: non più solo PowerShell, Visual Studio e Win32, ma anche shell Linux, package manager, toolchain GNU, Docker, Kubernetes locali, CUDA e workflow tipici dei server Linux. Noi, ad esempio, utilizziamo praticamente ogni giorno WSL sui nostri sistemi.

Cosa cambia con WSL Containers

Microsoft presenta WSL come uno strumento per eseguire ambienti GNU/Linux direttamente in Windows, con gran parte degli strumenti e delle applicazioni Linux che “semplicemente funzionano”, senza bisogno di alcuna modifica.

Nel 2025 il progetto WSL è diventato open source su GitHub; durante la conferenza Build 2026, inoltre, l’azienda di Redmond ha poi presentato una serie di funzioni per rendere Windows 11 una piattaforma più vicina alle esigenze reali di chi lavora tra Linux, cloud, container e applicazioni native. Di recente, inoltre, Microsoft ha avviato un progetto per portare in Windows le Coreutils Rust, ovvero i comandi Linux in versione Rust.

WSL Containers porta dentro WSL una gestione nativa del ciclo di vita dei container Linux. Il nuovo comando wslc consente di eseguire operazioni familiari a chi usa già strumenti come Docker o Podman: avvio di container, gestione delle immagini, pubblicazione delle porte, uso di volumi, reti dedicate, log, statistiche e rimozione delle risorse non più necessarie.

La release 2.9.3 di WSL cita esplicitamente funzioni come create, run, start, kill, export, prune e inspect per i container; aggiunge inoltre limiti per il singolo container tramite opzioni come --cpus, --memory e --ulimit, oltre alla possibilità di configurare la dimensione della memoria condivisa con --shm-size e i segnali di arresto. Microsoft sta cercando di costruire un’interfaccia completa, sufficientemente familiare da non spiazzare chi lavora già con i container Linux.

Perché Microsoft vuole un’esperienza container integrata in Windows

Molti sviluppatori Windows usano container Linux passando per soluzioni di terze parti. Docker Desktop, Podman Desktop e Rancher Desktop hanno risolto moltissimi problemi pratici, ma introducono installazione, aggiornamenti, policy aziendali e modelli di gestione separati dal sistema operativo. Per un singolo sviluppatore cambia poco; per un reparto IT che gestisce centinaia o migliaia di PC, invece, l’impatto è rilevante.

WSLC mette a disposizione, tramite WSL, un runtime Linux per i container accessibile da Windows: il sistema operativo di Redmond guadagna così una base nativa su cui anche altri strumenti potranno costruire esperienze integrate.

Un’applicazione Windows potrebbe usare un container Linux come componente interno per eseguire un tool, un motore di elaborazione, una dipendenza Linux o un servizio temporaneo, senza chiedere all’utente di installare manualmente un’intera distribuzione o una piattaforma container separata.

Un aspetto interessante potrebbe rivelarsi l’API (Application Programming Interface): Microsoft distribuisce il pacchetto NuGet Microsoft.WSL.Containers. L’idea è permettere a un’app Windows di verificare i prerequisiti WSL, creare una sessione, scaricare un’immagine, configurare un container, avviarlo, leggere stdout e stderr, scrivere su stdin, gestire segnali e terminare le risorse quando non servono più.

GPU, AI locale e carichi cloud-native

WSLC include il supporto GPU fin dalla “prima ora”: le note di rilascio citano la possibilità di creare container che usano la GPU tramite CDI, acronimo di Container Device Interface, e librerie o eseguibili GPU montati in modo accessibile anche a utenti non root.

Per gli sviluppatori AI e machine learning è un passaggio rilevante, perché WSL 2 è già usato per eseguire workflow CUDA, PyTorch, TensorFlow-DirectML e container con accelerazione hardware.

La presenza della GPU dentro i container WSL può semplificare test locali di modelli, tool di inferenza, elaborazioni multimediali, build accelerate e workload scientifici. Non trasforma però ogni notebook Windows in un server AI: restano i vincoli dei driver, della memoria video, della compatibilità CUDA o DirectML, delle immagini usate e del tipo di GPU installata.

Prestazioni: VirtIOFS, rete Consomme e memoria restituita a Windows

Accanto a WSLC, Microsoft sta modificando anche parti profonde dell’infrastruttura WSL.

La novità più concreta riguarda VirtIOFS, scelto come nuovo file system predefinito per WSL Containers. Secondo Microsoft, l’accesso ai file Windows può risultare fino a 2 volte più veloce. VirtIOFS nasce infatti per condividere file tra host e guest virtualizzati con meno overhead rispetto agli approcci più tradizionali, riducendo il costo del passaggio tra ambiente Windows e ambiente Linux.

Molti problemi storici di WSL e dei container su Windows ruotano attorno all’I/O: repository grandi, dipendenze npm o Composer, compilazioni C/C++, checkout Git con migliaia di file piccoli, database locali montati su directory condivise. Anche un miglioramento parziale può avere un impatto reale perché non tutto il lavoro di sviluppo consuma CPU o GPU; spesso il collo di bottiglia sta proprio nelle operazioni sui file.

Microsoft introduce poi una nuova modalità di rete sperimentale chiamata Consomme. L’obiettivo dichiarato è migliorare la compatibilità in ambienti con VPN, proxy e configurazioni aziendali complesse.

Consomme inoltra il traffico Linux attraverso Windows, permettendo alle applicazioni Linux di beneficiare dello stesso ambiente di rete, delle policy e delle integrazioni enterprise disponibili per le applicazioni Windows. Invece di trattare il guest Linux come un’isola separata, lo si avvicina al modello di rete dell’host.

C’è anche un miglioramento in tema memory reclaim, cioè nella capacità di restituire gradualmente memoria al sistema Windows quando la macchina virtuale Linux non la usa più. Build, container e database locali possono far crescere rapidamente il consumo di RAM: un rilascio più prevedibile della memoria riduce la sensazione di avere un ambiente Linux che “si tiene tutto” anche dopo la fine del lavoro.