1 18/05/2026 9 min

Verificare se la virtualizzazione è già attiva

Su Windows 10 e 11 la parola “virtualizzazione” copre due livelli diversi: il supporto del firmware della macchina e le funzioni di virtualizzazione offerte da Windows. Se il processore la supporta ma il firmware la tiene disabilitata, gli strumenti come Hyper-V, WSL2, Docker Desktop o i sandbox non partono correttamente. Se invece il firmware è già a posto ma manca la componente di Windows, il sistema resta operativo ma non può creare macchine virtuali o usare alcune funzionalità che si appoggiano a Hyper-V.

Il controllo più rapido si fa dal Task Manager. Apri Gestione attività, vai su Prestazioni e seleziona CPU. In basso, cerca la voce Virtualizzazione. Se leggi Abilitata, il firmware espone già VT-x, AMD-V o equivalente. Se leggi Disabilitata, il problema non è Windows: va corretto nel BIOS o nell’UEFI. Se la voce non compare, di solito stai guardando una macchina molto vecchia, un profilo firmware limitato, oppure un contesto virtuale che non espone la virtualizzazione annidata.

Un secondo controllo, più utile quando il Task Manager non basta, è il comando systeminfo. Da Prompt dei comandi o PowerShell esegui:

systeminfo

Nell’output cerca la sezione finale sui requisiti di Hyper-V. I campi più interessanti sono quelli che indicano estensioni di virtualizzazione nel firmware, SLAT e prevenzione esecuzione dati. Se uno di questi requisiti risulta assente, non ha senso forzare l’abilitazione di Hyper-V: prima va verificato il supporto hardware effettivo.

Capire cosa devi attivare davvero

Molti problemi nascono perché si confondono tre cose diverse. La prima è la virtualizzazione nel firmware, cioè l’impostazione del processore e della scheda madre. La seconda è Hyper-V, cioè la piattaforma di virtualizzazione di Windows. La terza è l’uso indiretto della virtualizzazione da parte di altri prodotti, per esempio WSL2 o alcune soluzioni di sicurezza che richiedono l’hypervisor di Windows attivo anche senza usare macchine virtuali classiche.

Se il tuo obiettivo è eseguire macchine virtuali in modo nativo, devi controllare sia il firmware sia le funzionalità di Windows. Se invece devi solo far partire WSL2 o Docker Desktop, spesso basta attivare le componenti corrette di Windows e avere la virtualizzazione nel firmware già abilitata. In pratica: firmware acceso, feature Windows corrette, riavvio pulito.

Attivare la virtualizzazione nel BIOS o nell’UEFI

La parte più delicata non è Windows, ma il firmware. Il nome dell’opzione cambia da produttore a produttore: Intel Virtualization Technology, VT-x, SVM Mode, AMD-V, Secure Virtual Machine o etichette simili. Su portatili aziendali spesso l’opzione è nascosta in menu avanzati o protetta da password amministrativa. Su molti desktop consumer è invece nel menu CPU, Advanced, Security o Configuration.

La procedura corretta è questa: riavvia il PC, entra nel firmware con il tasto indicato dal produttore, cerca la voce legata alla virtualizzazione e impostala su Enabled. Salva ed esci. Al riavvio torna in Windows e ricontrolla il Task Manager. Se la voce resta disabilitata, il firmware potrebbe non aver salvato, oppure stai guardando il profilo sbagliato se il dispositivo usa più livelli di configurazione.

Su alcuni sistemi conviene anche verificare che non ci siano impostazioni collegate che interferiscono, come avvio legacy, protezioni particolari o profili di sicurezza che limitano le estensioni CPU. Non esiste una regola unica, perché ogni produttore gestisce il menu in modo diverso. Se il dispositivo è aziendale e il menu è bloccato, la chiusura del problema passa dal reparto IT o dal vendor, non da un trucco lato Windows.

Attivare le funzionalità di Windows che usano Hyper-V

Quando il firmware è già a posto, il passo successivo è attivare le feature di Windows. Apri Attiva o disattiva funzionalità di Windows e controlla le caselle più comuni: Hyper-V, Piattaforma macchina virtuale, Piattaforma ipervisor di Windows e, se serve, Windows Subsystem for Linux. La combinazione esatta dipende dallo scenario.

Per aprire la schermata puoi usare il percorso grafico oppure il comando rapido:

optionalfeatures

Se devi abilitare Hyper-V completo, spunta le componenti richieste e conferma. Se invece ti serve solo il supporto per WSL2 o applicazioni che richiedono il motore di virtualizzazione di Windows, spesso basta la piattaforma macchina virtuale. Il punto chiave è non abilitare a caso tutto: ogni funzione in più aumenta un po’ la superficie del sistema e può cambiare il comportamento di software che usa altri hypervisor o driver di sicurezza.

Su Windows 11 Home non hai Hyper-V completo come su Pro o Enterprise, ma puoi comunque usare alcune funzioni che si appoggiano alla virtualizzazione del sistema. In quel caso l’errore tipico è cercare il pannello di Hyper-V e non trovarlo: non è un guasto, è una limitazione dell’edizione. La verifica va fatta sul campo Edizione Windows in Impostazioni > Sistema > Informazioni.

Verifica da riga di comando: quando il GUI non basta

La GUI è comoda, ma in assistenza remota o su sistemi già parzialmente rotti conviene passare da PowerShell. Per vedere lo stato delle feature più comuni usa dism:

dism /online /Get-Features /Format:Table

Cerca voci come Microsoft-Hyper-V-All, VirtualMachinePlatform e HypervisorPlatform. Lo stato Enabled conferma che la feature è attiva; Disabled indica che manca ancora il pezzo Windows, anche se il firmware è corretto. Se il comando restituisce errori di accesso o component store corrotto, hai un problema diverso: prima va verificata l’integrità del sistema, non la virtualizzazione in sé.

Per attivare una feature specifica senza passare dal pannello, usa un comando mirato. Per esempio, per la piattaforma macchina virtuale:

dism /online /Enable-Feature /FeatureName:VirtualMachinePlatform /All /NoRestart

Il parametro /NoRestart è utile se vuoi controllare prima l’effetto e riavviare solo quando sei pronto. Dopo il riavvio, ricontrolla lo stato con lo stesso comando. Se la feature torna a Enabled, hai chiuso il problema lato Windows.

Quando la virtualizzazione è attiva ma non funziona comunque

Qui di solito il guasto è in un layer diverso. Il caso più frequente è il firmware corretto ma l’hypervisor di Windows disattivato da configurazione di boot. Un’altra possibilità è il conflitto con software di terze parti che usa il proprio motore di virtualizzazione o filtra gli accessi al kernel. In ambienti aziendali entrano in gioco anche policy di sicurezza, VBS, Credential Guard e restrizioni applicate da criteri di gruppo.

Se Hyper-V non parte, controlla il registro eventi di Windows e lo stato dei servizi correlati. I log utili sono quelli di Hyper-V-Hypervisor, Hyper-V-Worker e, se usi WSL2, i log del sottosistema Linux. In molti casi basta aprire Visualizzatore eventi e cercare errori al momento del boot o del tentativo di avvio della VM. Il dettaglio del messaggio è più utile di un generico “non funziona”.

Un altro controllo pratico è verificare se il boot loader di Windows ha l’hypervisor abilitato. In PowerShell elevato puoi usare:

bcdedit /enum {current}

Cerca la voce legata all’hypervisor. Se è impostata in modo incoerente rispetto allo scenario, alcune feature possono restare installate ma non effettivamente operative. Questo tipo di controllo è molto utile quando il sistema è stato modificato da tool di tuning, script di hardening o aggiornamenti che hanno alterato il boot configuration.

Impatto su WSL2, Docker e software di sicurezza

La virtualizzazione in Windows non serve solo alle macchine virtuali classiche. WSL2 usa un kernel Linux leggero che dipende dalla piattaforma di virtualizzazione. Docker Desktop, in molte configurazioni, usa lo stesso supporto. Alcuni agent di sicurezza e alcuni sandbox richiedono che l’hypervisor sia disponibile, anche se l’utente non apre mai Hyper-V Manager.

Per questo motivo il sintomo non è sempre “non parte la VM”. A volte il problema si presenta come un container che non si avvia, una distribuzione WSL bloccata o un errore generico di compatibilità. In questi casi la verifica del firmware e delle feature Windows resta il primo passo, perché il layer è lo stesso. Se il supporto è attivo ma il software continua a fallire, allora bisogna guardare la sua configurazione specifica, i driver installati o eventuali policy di sicurezza che impediscono l’uso dell’hypervisor.

Ordine corretto di diagnosi

Quando devi chiudere il ticket in fretta, evita di saltare direttamente alla reinstallazione. L’ordine giusto è semplice: prima conferma che il firmware esponga la virtualizzazione, poi verifica che Windows abbia le feature necessarie, poi controlla i log e solo alla fine valuta conflitti software o policy. Questo riduce i falsi positivi e ti evita di toccare componenti che non c’entrano nulla.

Se sei davanti a una macchina fisica, il controllo più affidabile resta il BIOS o UEFI. Se sei su una VM, devi capire se l’host espone la virtualizzazione annidata. Se sei su un PC aziendale, controlla anche che il vendor non abbia bloccato il menu. Sono tre scenari diversi, ma il sintomo iniziale è spesso identico: una funzione che chiede virtualizzazione e non la trova.

Checklist operativa rapida

Se vuoi una sequenza corta e pulita, usa questa:

  1. Apri Task Manager e verifica Virtualizzazione in CPU.
  2. Se è disabilitata, entra nel BIOS/UEFI e abilita Intel VT-x o AMD-V/SVM.
  3. Su Windows apri optionalfeatures e abilita le componenti richieste: Hyper-V, Piattaforma macchina virtuale o Piattaforma ipervisor di Windows.
  4. Riavvia e ricontrolla con systeminfo e, se serve, con dism /online /Get-Features /Format:Table.
  5. Se il problema resta, apri il Visualizzatore eventi e cerca errori Hyper-V, WSL o boot configuration.

Questa sequenza funziona bene perché separa i livelli: prima hardware, poi sistema operativo, poi applicazione. È il modo più veloce per evitare di perdere tempo su sintomi che sembrano uguali ma hanno cause diverse.

Quando fermarsi e chiedere un dato in più

Se non sai se stai lavorando su macchina fisica o virtuale, se l’edizione di Windows è Home o Pro, oppure se il problema riguarda Hyper-V, WSL2 o Docker, non conviene andare a tentativi. In quei casi la chiusura corretta è raccogliere tre informazioni: modello macchina o tipo di host, esito di systeminfo, e stato della voce Virtualizzazione nel Task Manager. Con quei tre dati si capisce quasi sempre dove intervenire senza toccare altro.