1,702 25/03/2026 07/04/2026 6 min

Su Windows 11 da sysadmin il punto non è “far partire WSL2”. Il punto è decidere come gestirlo in produzione quando il firewall si resetta, un servizio smette di rispondere o il disco virtuale cresce troppo.

In questo scenario il confronto utile è tra due approcci: gestione leggera con LxssManager e gestione più rigida con feature Hyper-V. Il primo è più rapido e comodo per postazioni tecniche. Il secondo è più prevedibile per backup, isolamento e recovery controllato.

Il caso concreto qui è questo: una macchina Win 11 usata da sysadmin, con WSL2 per script, tool Linux e accesso a servizi interni. Dopo un riavvio, il servizio LxssManager riparte, ma il firewall lascia chiusa la porta usata dal servizio in ascolto dentro la distro. Il risultato è semplice: il tool funziona in locale, ma dall’esterno sembra spento.

Note: il problema non è solo la porta. Spesso cambiano anche profilo rete, regole dinamiche e ordine di avvio. Per questo conviene scegliere l’approccio giusto prima dell’incidente.

Prerequisiti

  • Windows 11 Pro o Enterprise.
  • WSL2 già attivo con una distro Linux installata.
  • Permessi amministrativi locali.
  • Accesso a PowerShell come amministratore.
  • Spazio libero sufficiente per esportare il disco VHDX.

Warning: se il VHDX è già vicino al limite, il backup “a caldo” può fallire o produrre un file lento da ripristinare.

Step 1: capire il nodo, non solo il sintomo

Prima di toccare firewall o backup, verifica se il problema è nella rete, nel servizio o nella distro. Serve perché i due approcci reagiscono in modo diverso.

Con LxssManager lavori sul runtime WSL e sulle sue regole dinamiche. Con Hyper-V ragioni più da infrastruttura: più controllo, meno improvvisazione.

Get-Service LxssManager, hns, vmcompute | Format-Table Name, Status, StartType

# Output:

Name         Status  StartType
----         ------  ---------
LxssManager  Running Automatic
hns          Running Automatic
vmcompute    Running Automatic

Se uno di questi servizi non è stabile, il problema non è la sola porta. Prima sistema l’avvio, poi il firewall.

Step 2: scegliere LxssManager quando serve velocità

Questo approccio conviene quando usi WSL2 come cassetta degli attrezzi quotidiana. È adatto a script, test locali, proxy temporanei e servizi non critici.

Il vantaggio è pratico: meno passaggi, meno overhead, meno manutenzione. Il rovescio della medaglia è che il comportamento di rete può cambiare dopo update, reboot o riattivazione del servizio.

Qui la regola è semplice: apri solo la porta necessaria e vincolala al profilo corretto. Evita regole larghe su Any se non ti serve davvero.

New-NetFirewallRule -DisplayName "WSL2 app 3000" `
  -Direction Inbound -Action Allow -Protocol TCP -LocalPort 3000 `
  -Profile Private

# Output:

Name                          : {d1f4c0e2-...}
DisplayName                   : WSL2 app 3000
Enabled                       : True

Questo è il punto forte dell’approccio leggero: risolvi il sintomo rapidamente e con poco impatto sul resto del sistema.

Quando sceglierlo

  • Hai bisogno di partire subito dopo il boot.
  • La distro serve a uno o due servizi interni.
  • Il rischio principale è operativo, non normativo.
  • Accetti di rifare la regola dopo alcuni cambi di rete.

Step 3: scegliere Hyper-V quando conta il ripristino

Se la priorità è backup affidabile e recovery ripetibile, l’approccio Hyper-V è più solido. Non rende WSL2 “più veloce”. Lo rende più prevedibile.

Qui il vantaggio è il controllo sul disco virtuale e sul ciclo di stop/export/import. È utile quando la distro contiene configurazioni, chiavi, container leggeri o script che non vuoi perdere.

Il compromesso è chiaro: più disciplina, più passaggi, più tempo di manutenzione. In cambio ottieni un flusso di backup che puoi documentare e testare.

wsl --shutdown
Copy-Item "$env:LOCALAPPDATA\Packages\*\LocalState\ext4.vhdx" D:\Backup\WSL2\ -Force

# Output:

1 file copiato.

Note: il percorso reale cambia in base alla distro. Cerca il file ext4.vhdx sotto LocalState. Non copiare a caso cartelle incomplete.

Quando sceglierlo

  • La distro è importante per lavoro o automazione.
  • Vuoi un backup verificabile del VHDX.
  • Devi ripristinare su una macchina diversa.
  • Ti serve ridurre il rischio di corruzione da copia a caldo.

Step 4: fare il backup del VHDX in modo pulito

Per un backup serio conviene fermare WSL2 prima della copia. Serve perché il file VHDX può essere consistente solo quando la VM è spenta.

Questo passaggio è uno dei motivi per preferire Hyper-V quando il backup ha priorità. LxssManager è più comodo, ma non sempre basta per una copia affidabile.

wsl --shutdown
robocopy "$env:LOCALAPPDATA\Packages\CanonicalGroupLimited...\LocalState" "D:\Backup\WSL2" ext4.vhdx /R:1 /W:1

# Output:

-----------------------------------------------------------------
   ROBOCOPY     ::     Robust File Copy for Windows
-----------------------------------------------------------------
   Started : ...
   Ended   : ...
   Files : 1
   Copied : 1

Se vuoi un ripristino rapido, conserva anche il nome della distro e la versione di Windows. Ti risparmia ore quando devi ricostruire il profilo.

Step 5: evitare il problema firewall dopo il reboot

Il caso classico è questo: dopo il riavvio il servizio risponde, ma il traffico entra solo in locale. La causa di solito è una regola firewall legata al profilo sbagliato o a una porta cambiata.

Con LxssManager conviene verificare il profilo di rete attivo e la regola effettiva. Con Hyper-V il controllo è simile, ma spesso la disciplina è migliore perché il servizio è trattato come componente da infrastruttura.

Get-NetFirewallRule -DisplayName "WSL2 app 3000" | Get-NetFirewallPortFilter
Get-NetConnectionProfile

# Output:

Protocol : TCP
LocalPort: 3000

Name             : Ethernet
NetworkCategory  : Private

Se il profilo è Public, la regola su Private non basta. Se la porta è diversa, la regola va aggiornata, non “allargata” a caso.

Step 6: ripristinare una distro senza portarsi dietro il caos

Se il VHDX è sano ma la distro non parte bene, non copiare solo file a mano. Reimporta in modo controllato. È il motivo per cui l’approccio Hyper-V è preferibile nei casi delicati.

wsl --import MyDistro D:\WSL\MyDistro D:\Backup\WSL2\ext4.vhdx --version 2

# Output:

Operazione completata correttamente.

Questo comando è utile quando vuoi isolare il ripristino dall’installazione originale. Se qualcosa va storto, la vecchia distro resta intatta.

Verifica finale

La verifica non deve limitarsi a “parte”. Deve confermare tre cose: servizio attivo, porta raggiungibile, backup ripristinabile.

wsl -l -v
Test-NetConnection 127.0.0.1 -Port 3000
Get-ChildItem D:\Backup\WSL2\ext4.vhdx | Select-Object Name, Length

# Output:

Name      State   Version
----      -----   -------
MyDistro  Running 2

TcpTestSucceeded : True

Name      Length
----      ------
ext4.vhdx  42949672960

Se il test porta fallisce ma il servizio è running, il problema è quasi sempre nel firewall o nel bind dell’app dentro WSL2. Se il VHDX non è presente, il backup non è da considerare valido.

Troubleshooting

Errore 1: “No mapping between account names and security IDs was done.”

Causa: la regola firewall usa un gruppo o account non risolto correttamente dopo un cambio profilo o dominio.

Fix:

Remove-NetFirewallRule -DisplayName "WSL2 app 3000"
New-NetFirewallRule -DisplayName "WSL2 app 3000" -Direction Inbound -Action Allow -Protocol TCP -LocalPort 3000 -Profile Private

Errore 2: “The process cannot access the file because it is being used by another process.”

Causa: stai copiando il VHDX mentre WSL2 è ancora attivo.

Fix:

wsl --shutdown
Start-Sleep -Seconds 5
robocopy "...\LocalState" "D:\Backup\WSL2" ext4.vhdx /R:1 /W:1

Errore 3: “Element not found.”

Causa: stai puntando a una distro rimossa, rinominata o importata in un percorso diverso.

Fix:

wsl -l -v
Get-ChildItem "$env:LOCALAPPDATA\Packages" -Directory | Select-Object Name

Conclusione

Se ti serve rapidità, LxssManager è la strada giusta. Se ti serve ripristino affidabile, Hyper-V e backup del VHDX vincono quasi sempre.

Il prossimo passo concreto è definire una policy: una regola firewall per ogni servizio WSL2, più un export settimanale del VHDX con test di restore mensile.

Note: in ambienti mission-critical, la scelta migliore non è “una soluzione sola”. È separare il piano operativo dal piano di recovery.