Usare VirtualBox e Hyper-V insieme su Windows 10

Su Windows 10, far convivere VirtualBox e Hyper-V non è più un caso limite: dipende dalla versione di Windows, dall’uso di VT-x/AMD-V e da come vengono esposte le estensioni di virtualizzazione alle applicazioni di terze parti. Il punto pratico è semplice: se Hyper-V è attivo, VirtualBox può funzionare, ma spesso con un backend diverso, meno performante e con alcune limitazioni. Se invece ti serve il massimo delle prestazioni su VirtualBox, di norma conviene disattivare Hyper-V e i componenti che si appoggiano allo stesso hypervisor.

La domanda vera non è “si può fare?”, ma “in quale scenario vale la pena farlo?”. Se usi Docker Desktop, WSL2, Windows Sandbox o funzionalità di sicurezza basate su virtualizzazione, Hyper-V o il suo stack correlato sono spesso già parte dell’ambiente. In quel caso VirtualBox non sparisce, ma smette di essere il classico hypervisor bare-metal e passa a integrarsi con l’hypervisor Microsoft. Questo cambia comportamento, compatibilità e diagnostica.

Cosa succede davvero quando Hyper-V è attivo

Quando Hyper-V è abilitato, prende il controllo della virtualizzazione hardware a livello di root partition. Le altre piattaforme, incluso VirtualBox, non accedono direttamente a VT-x/AMD-V nello stesso modo di prima. In pratica VirtualBox può ancora avviare macchine virtuali, ma lo fa appoggiandosi all’hypervisor Microsoft tramite un layer di compatibilità. Il risultato tipico è questo: funziona, ma non sempre con le stesse prestazioni, e alcuni guest o feature avanzate possono comportarsi in modo diverso rispetto alla modalità classica.

Per l’amministratore questo significa due cose. Primo: un errore di configurazione non è sempre un bug di VirtualBox, spesso è un effetto collaterale di Hyper-V o di un suo componente satellite. Secondo: la diagnosi non si fa guardando solo l’applicazione, ma anche lo stato dell’hypervisor di Windows e dei servizi che lo abilitano.

Quando conviene tenerli entrambi

Tenere attivi Hyper-V e VirtualBox insieme ha senso se il tuo obiettivo è la compatibilità operativa, non la massima efficienza. È una scelta sensata quando devi usare contemporaneamente ambienti diversi: ad esempio una VM di test in VirtualBox, WSL2 per tooling Linux e Docker Desktop per build e container. In questi casi la latenza aggiuntiva di VirtualBox in modalità “compatibile” è spesso accettabile, purché tu non stia facendo benchmark o carichi sensibili al nesting.

Se invece il requisito è far girare VM con I/O intenso, nested virtualization affidabile o workload che dipendono da timing più stabile, la soluzione migliore è scegliere un solo hypervisor per volta. VirtualBox rende meglio quando Hyper-V è spento; Hyper-V è più adatto se vuoi integrare il lavoro con strumenti nativi di Windows e con l’ecosistema Microsoft.

Verifiche preliminari prima di toccare la configurazione

Prima di cambiare stato ai componenti, conviene capire cosa è già attivo. Le verifiche minime sono tre: versione di Windows, presenza dell’hypervisor e disponibilità della virtualizzazione nel firmware. Senza questi dati, si rischia di disattivare il pezzo sbagliato e attribuire a VirtualBox problemi che arrivano invece dal boot manager o da un’impostazione BIOS/UEFI.

Da Prompt dei comandi o PowerShell, controlla la build di Windows e il ruolo dell’hypervisor con un paio di comandi semplici:

systeminfo | findstr /i "Hyper-V"
wmic os get Caption,Version,BuildNumber

Se il sistema segnala che è stato rilevato un hypervisor, sei già nel caso in cui VirtualBox non sta usando il percorso tradizionale. Per verificare il firmware, puoi usare anche il Task Manager: scheda Prestazioni, CPU, voce “Virtualizzazione”. Se è disattivata, nessun software risolverà il problema da solo: va abilitata nel BIOS/UEFI.

Disattivare Hyper-V quando serve massima compatibilità con VirtualBox

Se il tuo obiettivo è usare VirtualBox nel modo più vicino possibile alla modalità nativa, la strada più pulita è disattivare Hyper-V e i componenti che lo agganciano. Questo è un change controllato: impatta WSL2, Docker Desktop con backend Hyper-V/WSL2, Windows Sandbox e, in alcuni casi, funzioni di sicurezza basate su virtualizzazione. Prima di procedere, valuta il blast radius: se disattivi Hyper-V, alcune VM o tool di sviluppo smetteranno di avviarsi fino al ripristino.

La via più rapida è usare BCDEdit per impedire il lancio dell’hypervisor al boot. È reversibile e pulita se annoti il valore iniziale.

bcdedit /set hypervisorlaunchtype off

Dopo il riavvio, verifica che l’hypervisor non risulti più attivo:

systeminfo | findstr /i "A hypervisor has been detected"

Se il testo non compare, VirtualBox dovrebbe tornare a usare il percorso classico. Se invece restano attivi componenti come Windows Hypervisor Platform o Virtual Machine Platform, potresti non avere il risultato atteso: in quel caso controlla le funzionalità opzionali di Windows da “Attiva o disattiva funzionalità di Windows”.

Per un rollback immediato, riattiva l’hypervisor al boot:

bcdedit /set hypervisorlaunchtype auto

Lasciare Hyper-V attivo e usare VirtualBox in modalità compatibile

Se non puoi spegnere Hyper-V, la configurazione corretta è accettare la convivenza e ridurre le aspettative sulle prestazioni. In questa modalità VirtualBox continua a essere utile per test rapidi, VM legacy e ambienti che non richiedono throughput elevato. La differenza pratica si vede soprattutto su CPU scheduling, I/O disco e networking bridged in scenari specifici.

Qui il lavoro non è tanto “abilitare qualcosa”, quanto evitare conflitti. Controlla che non ci siano versioni vecchie di VirtualBox, perché le release recenti gestiscono meglio la presenza dell’hypervisor Microsoft. In un ambiente stabile conviene anche uniformare l’estensione pack e la versione del software host.

Un controllo utile è il log della VM, che di solito chiarisce se VirtualBox sta rilevando Hyper-V e quale backend sta usando. Il file da guardare è nella cartella della macchina virtuale, tipicamente `VBox.log`.

type "C:\Users\%USERNAME%\VirtualBox VMs\NOME_VM\Logs\VBox.log" | findstr /i "Hyper-V"

Se nel log trovi riferimenti al supporto Hyper-V o al motore di virtualizzazione paravirtualizzato, significa che la VM non è in modalità classica. Non è un errore in sé: è un indizio utile per capire perché le prestazioni o il comportamento differiscono da quanto ti aspetti.

Il caso più comune: Docker Desktop, WSL2 e VirtualBox sullo stesso host

Questo è il punto in cui molti ambienti di sviluppo si complicano. Docker Desktop con backend WSL2 richiede la virtualizzazione di Windows, WSL2 si appoggia allo stesso stack, e VirtualBox diventa il terzo attore. Se devi far convivere tutto, la priorità è decidere chi ha la precedenza nel workflow quotidiano. Non ha senso inseguire la massima performance di VirtualBox se poi perdi WSL2 o Docker, e viceversa.

Una strategia pratica è usare Hyper-V attivo come base del desktop di sviluppo e riservare VirtualBox a VM che non sono sensibili alle prestazioni. Se invece VirtualBox è il centro del lavoro, allora conviene spostare Docker su un backend diverso o usare un host separato. In ambienti di team questo va documentato, perché altrimenti metà del gruppo avrà VM lente e l’altra metà avrà tool di sviluppo che non partono.

Rete: bridge, NAT e differenze quando Hyper-V entra in mezzo

La parte di rete è spesso sottovalutata. Con Hyper-V attivo, alcune VM VirtualBox possono mostrare comportamento diverso su NAT, bridged e host-only. Non è raro vedere problemi di discovery, timeout verso gateway interni o differenze nel MAC filtering se il contesto è aziendale. Il controllo minimo è sempre lo stesso: raggiungibilità dell’IP guest, DNS dentro la VM e modalità di rete assegnata nel pannello di VirtualBox.

Se una VM non prende rete, non partire dal guest: verifica prima l’adattatore in VirtualBox e la presenza del bridge o del NAT corretto. In un ambiente Windows 10 con stack misto, i problemi possono venire anche dal driver di rete virtuale o dalla presenza di software di sicurezza che intercetta l’IP forwarding.

Un test rapido lato guest è verificare gateway e DNS:

ipconfig /all
ping 8.8.8.8
nslookup example.com

Se `ping 8.8.8.8` funziona ma `nslookup` no, il problema è DNS. Se non risponde neppure il gateway, la causa è più probabilmente nella modalità di rete o nel binding del driver host.

Prestazioni: cosa misurare prima di dichiarare il problema “di VirtualBox”

Quando un utente dice “VirtualBox è lento con Hyper-V”, la prima domanda è: lento in che senso? Per una diagnosi utile servono almeno una metrica e un confronto. Le più pratiche sono tempo di boot della VM, p95 della latenza disco dentro il guest e saturazione CPU durante un carico ripetibile. Senza questo, si finisce a discutere impressioni.

Se vuoi un controllo veloce, usa un benchmark ripetibile dentro la VM o misura il tempo di avvio del servizio che ti interessa. Anche una semplice differenza tra cold boot e warm boot può dirti se il collo di bottiglia è sullo storage virtuale o sullo scheduling dell’hypervisor.

Un esempio pratico: se la VM impiega il doppio ad avviarsi solo quando Hyper-V è abilitato, ma il resto del sistema resta stabile, il problema non è “Windows rotto”. È un compromesso architetturale. A quel punto devi decidere se accettare il trade-off o separare i ruoli su host diversi.

Diagnostica rapida quando VirtualBox non parte o mostra errori strani

Gli errori più frequenti sono quelli che parlano di VT-x non disponibile, impossibilità di accedere alla virtualizzazione o VM che si chiude subito. In presenza di Hyper-V, il messaggio può essere fuorviante perché il supporto hardware non è davvero assente: è occupato dal layer Microsoft. La falsificazione più rapida è controllare se l’hypervisor è attivo e leggere il log della VM.

Tre verifiche in meno di cinque minuti:

1. Controlla `systeminfo` per la presenza dell’hypervisor.
2. Apri `VBox.log` della VM e cerca riferimenti a Hyper-V o al motore di virtualizzazione usato.
3. Verifica in BIOS/UEFI che la virtualizzazione sia abilitata, guardando la voce “Virtualization”, “Intel VT-x” o “SVM”.

Se uno di questi tre punti fallisce, hai già l’ipotesi più probabile. Non serve cambiare dieci impostazioni insieme: prima isola il livello che blocca l’avvio, poi intervieni.

Scelta operativa: tenere o spegnere Hyper-V

La regola pratica è questa. Se il desktop Windows deve servire sviluppo moderno, WSL2 e container, tieni Hyper-V e accetta VirtualBox come strumento secondario. Se invece VirtualBox è il tool primario per lab, test di appliance o ambienti legacy, spegni Hyper-V quando lavori su quelle VM. Non c’è una scelta universale, c’è una scelta coerente con il carico.

In un parco macchine gestito bene, questa decisione va standardizzata. Niente configurazioni “a sentimento” sul singolo laptop: uno stato documentato evita ore perse a rincorrere differenze tra host. Se il team usa entrambi gli stack, conviene definire un profilo per ciascun ruolo: host sviluppo Microsoft-centric, host laboratorio VirtualBox-centric.

Checklist finale da usare prima di aprire un ticket

Se qualcosa non torna, raccogli questi dati prima di cambiare altro:

• Versione e build di Windows con `wmic os get Caption,Version,BuildNumber`.
• Stato dell’hypervisor con `systeminfo`.
• Versione di VirtualBox e contenuto di `VBox.log` della VM problematica.
• Stato della virtualizzazione nel Task Manager o nel BIOS/UEFI.
• Modalità di rete della VM e sintomi osservati: boot, CPU, rete, storage.

Con questi elementi si capisce subito se il problema è di compatibilità, di configurazione o di aspettativa sbagliata sul comportamento dell’hypervisor. Assunzione: Windows 10 recente, VirtualBox aggiornato e accesso amministrativo locale alla macchina host.