1 15/10/2026 10 min

Quando il nested virtualization in VirtualBox serve davvero

Il nested VTX/AMD-V in VirtualBox non è un interruttore “di comodità”: serve quando una macchina virtuale deve eseguire a sua volta un hypervisor o un ambiente che richiede estensioni di virtualizzazione hardware. Il caso classico è un lab con altre VM annidate, un nodo Kubernetes con un runtime che si appoggia a un hypervisor, oppure test di software che controlla la presenza di VT-x o AMD-V dentro la guest. Se il supporto non è esposto, la VM interna parte lenta, fallisce in fase di bootstrap o segnala che la virtualizzazione hardware non è disponibile.

Su VirtualBox la funzione esiste da tempo, ma il comportamento reale dipende da tre fattori: CPU host, supporto BIOS/UEFI, e configurazione dell’hypervisor host. Su Windows la situazione è spesso più delicata perché Hyper-V, VBS, WSL2 e Memory Integrity possono sottrarre o mediare le estensioni hardware. Su Linux il problema è più spesso legato a KVM già attivo sul sistema host o a moduli non caricati correttamente.

Prima distinzione: nested virtualization e passthrough delle estensioni

In VirtualBox non stai “dando” direttamente la CPU alla VM: stai chiedendo all’hypervisor di esporre alla guest una vista compatibile con VT-x o AMD-V. In pratica, la VM vede un processore che sembra supportare la virtualizzazione, ma il lavoro vero resta mediato dall’host. Questo ha conseguenze pratiche: la compatibilità è buona per ambienti di test, meno per carichi intensivi o benchmark realistici.

Su host Intel si parla comunemente di VT-x; su host AMD di AMD-V. VirtualBox usa un’impostazione equivalente per entrambi, ma il nome del toggle varia a seconda della versione e della UI. In alcuni casi trovi esplicitamente “Enable Nested VT-x/AMD-V”, in altri la casella è meno evidente e la funzione è presente solo via CLI o file XML della VM. Se la GUI non mostra l’opzione, non significa automaticamente che il supporto non esista: spesso è solo nascosto da vincoli dell’host o da una versione non aggiornata.

Prerequisiti che vanno verificati prima di toccare la VM

La sequenza corretta è: CPU compatibile, virtualizzazione attiva nel firmware, host non in conflitto con altri hypervisor, VirtualBox aggiornato. Saltare uno di questi punti porta a diagnosi sbagliate. Il nested virtualization non si “aggiusta” dentro la guest se l’host non lo espone già.

  1. Verifica che CPU e firmware supportino la virtualizzazione. Su Windows apri Task Manager, scheda Prestazioni, CPU, e controlla la voce Virtualizzazione: Abilitata. Su Linux usa lscpu | grep -Ei 'Virtualization|VT-x|AMD-V' e cerca anche il flag vmx o svm in /proc/cpuinfo.

  2. Controlla che non ci siano conflitti con altri hypervisor. Su Windows, Hyper-V, Windows Hypervisor Platform e VBS possono cambiare il comportamento di VirtualBox. Su Linux, KVM può restare presente nel sistema ma non deve occupare la scena se vuoi che VirtualBox gestisca direttamente la virtualizzazione annidata.

  3. Aggiorna VirtualBox e Extension Pack alla stessa major version, se usi funzionalità che lo richiedono. Versioni disallineate non sempre rompono il nested, ma aumentano il rumore diagnostico e introducono differenze tra GUI e comportamento effettivo.

Abilitare nested VTX/AMD-V su Windows

Su Windows l’ostacolo più comune non è VirtualBox, ma il layer di virtualizzazione di sistema. Se Hyper-V è attivo, VirtualBox può funzionare in modalità compatibile, ma il nested passthrough può non comportarsi come atteso. Per questo conviene partire dall’osservazione dell’host, non dalla VM.

  1. Apri Task Manager e verifica in Prestazioni > CPU che la virtualizzazione risulti abilitata. Se è disabilitata, entra nel BIOS/UEFI e attiva Intel VT-x o AMD SVM.

  2. Controlla se Hyper-V o componenti affini sono attivi. Da prompt elevato esegui:

    bcdedit /enum {current}

    Cerca eventuali configurazioni che indicano hypervisor avviato. Se il sistema usa Hyper-V, valuta se il tuo scenario richiede VirtualBox “puro” oppure compatibilità con il layer Microsoft. Per un lab di nested virtualization, spesso conviene disabilitare temporaneamente i componenti che agganciano l’hypervisor.

  3. In VirtualBox, apri la VM interessata, vai in Impostazioni > Sistema > Processore o nella sezione dedicata alla virtualizzazione, e abilita Nested VT-x/AMD-V se la voce è disponibile. In alcune versioni, la casella compare solo se la VM è spenta.

  4. Se la GUI non espone il toggle, usa la CLI di VirtualBox. Il comando tipico è:

    VBoxManage modifyvm "NOME_VM" --nested-hw-virt on

    La sintassi può variare leggermente in base alla release; se il comando fallisce, verifica con VBoxManage modifyvm --help o con la pagina di aiuto locale della tua versione.

  5. Riavvia la VM e controlla dentro la guest se il supporto è visibile. Su Linux guest, ad esempio, puoi usare:

    lscpu | grep -Ei 'Virtualization|VT-x|AMD-V'
cat /proc/cpuinfo | grep -E 'vmx|svm' | head

    Se il nested è esposto correttamente, i flag pertinenti dovrebbero comparire o la piattaforma di virtualizzazione interna dovrebbe smettere di segnalare assenza di hardware support.

Abilitare nested VTX/AMD-V su Linux

Su Linux il percorso è spesso più lineare, ma dipende da come il kernel gestisce i moduli di virtualizzazione. Se usi una distro desktop recente, VirtualBox di solito lavora bene con il kernel standard; se invece hai KVM, libvirt o altri hypervisor installati, devi capire chi sta usando davvero l’hardware di virtualizzazione.

  1. Verifica il supporto CPU e firmware con:

    lscpu | grep -Ei 'Virtualization|VT-x|AMD-V'
grep -E 'vmx|svm' /proc/cpuinfo | head

    Se non vedi vmx su Intel o svm su AMD, il problema è a monte: BIOS/UEFI o CPU senza estensioni compatibili.

  2. Controlla se il modulo VirtualBox è caricato e se la VM è spenta prima della modifica:

    lsmod | grep vbox
VBoxManage list vms

    Se il driver host non è attivo, la GUI può mostrare opzioni incomplete o non aggiornare lo stato della VM.

  3. Abilita il nested per la VM interessata:

    VBoxManage modifyvm "NOME_VM" --nested-hw-virt on

    Se stai configurando più VM, conviene fare il change in modo esplicito e versionabile, così da non dipendere dalla memoria dell’operatore.

  4. Riavvia la VM e verifica dall’interno la presenza dei flag di virtualizzazione o l’esito del software che li richiede. Se usi una guest Linux con KVM, il test più semplice è controllare se /dev/kvm esiste e se i moduli possono caricarsi:

    ls -l /dev/kvm
lsmod | grep kvm

Se la voce non compare: il problema di solito non è la VM

Quando il toggle non compare nella GUI, le cause più comuni sono tre: host senza virtualizzazione attiva nel firmware, conflitto con un hypervisor esterno, oppure versione di VirtualBox troppo vecchia rispetto al comportamento atteso. In ambiente Windows, la presenza di Hyper-V o VBS è spesso il colpevole silenzioso. In Linux, invece, può essere un modulo KVM già operativo o una configurazione del kernel che non lascia margine a VirtualBox.

Se vuoi una verifica rapida senza cambiare nulla, confronta il comportamento di una VM nuova e minimale con quello della VM problematica. Se la nuova VM mostra l’opzione e la vecchia no, il problema può essere un file di configurazione della macchina, non l’host. In quel caso conviene fare un confronto del file .vbox o esportare la configurazione dalla GUI e verificare le differenze.

Conflitti tipici su Windows: Hyper-V, WSL2 e integrità memoria

Il caso più frequente in assistenza è questo: VirtualBox funziona, ma il nested non passa o si comporta in modo incoerente. La causa è spesso il fatto che Windows sta già eseguendo un hypervisor nativo. WSL2 e alcune funzioni di sicurezza basate su virtualizzazione possono attivare lo stack Hyper-V anche quando l’utente pensa di non usarlo.

  1. Controlla lo stato dell’hypervisor con:

    systeminfo.exe

    Nell’output cerca la sezione relativa ai requisiti di Hyper-V e alla presenza di un hypervisor rilevato.

  2. Se devi fare test controllati, disattiva temporaneamente i componenti che usano l’hypervisor, poi riavvia. Il rollback deve essere tracciato, perché togliere questi componenti può impattare WSL2, Docker Desktop e altre dipendenze.

  3. Dopo il riavvio, ripeti la verifica nella GUI di VirtualBox o con VBoxManage showvminfo "NOME_VM" per vedere se il nested risulta abilitato.

Qui il punto non è “disabilitare tutto a caso”, ma capire se l’obiettivo è un host Windows pulito per laboratori di virtualizzazione oppure un ambiente di sviluppo che deve convivere con più stack. Nel secondo caso, il nested di VirtualBox può essere tecnicamente disponibile ma meno prevedibile.

Verifiche dentro la guest: non fidarti solo della GUI dell’host

La conferma vera è sempre dentro la guest. L’host può dirti che l’opzione è attiva, ma la prova pratica è che il sistema interno veda le estensioni e che il software target parta senza errori di virtualizzazione. Questo vale soprattutto quando la guest è un’altra VM o un sistema che usa KVM, Hyper-V o equivalenti.

  1. Su Linux guest, controlla i flag CPU:

    lscpu | grep -Ei 'Virtualization|vmx|svm'
cat /proc/cpuinfo | grep -E 'vmx|svm' | head

  2. Se la guest deve usare KVM, verifica la presenza di /dev/kvm e dei moduli:

    ls -l /dev/kvm
modprobe kvm_intel || modprobe kvm_amd

  3. Se la guest è Windows e il software richiede virtualizzazione, controlla in Task Manager o con strumenti di diagnostica della piattaforma che la virtualizzazione sia disponibile. Se il software continua a segnalare assenza di supporto, il problema può essere il tipo di emulazione CPU esposto da VirtualBox, non il nested in sé.

Limiti reali: performance, compatibilità e aspettative corrette

Il nested VTX/AMD-V in VirtualBox è utile, ma non è il posto giusto per misurare prestazioni o latenza di virtualizzazione. Ogni livello aggiuntivo introduce overhead e variabilità. Se stai testando cluster, orchestratori o hypervisor annidati, misura sempre l’effetto sul tempo di boot, sulla saturazione CPU e sulla reattività I/O, non solo sul fatto che “parte”.

Un errore comune è confondere compatibilità funzionale con stabilità operativa. Una VM nested che avvia una seconda VM non significa che sia adatta a carichi sostenuti. Se il tuo obiettivo è un laboratorio ripetibile, va bene. Se vuoi un ambiente di preproduzione realistico, spesso conviene usare un host con KVM diretto, ESXi o Hyper-V nativo, a seconda del caso d’uso.

Procedura pratica consigliata, in ordine sicuro

  1. Conferma la virtualizzazione nel firmware e nel sistema operativo host.

  2. Escludi conflitti con Hyper-V, WSL2, VBS o KVM già attivo.

  3. Aggiorna VirtualBox e, se serve, Extension Pack alla stessa versione principale.

  4. Abilita nested VT-x/AMD-V nella VM spenta, via GUI o con VBoxManage modifyvm "NOME_VM" --nested-hw-virt on.

  5. Riavvia la VM e verifica dall’interno la presenza dei flag e il comportamento del software target.

  6. Se il risultato non cambia, confronta la configurazione della VM con una VM nuova e minimale per isolare problemi di file di configurazione o snapshot vecchi.

Rollback e controllo delle modifiche

La modifica è reversibile: basta disattivare il nested e riavviare la VM. In CLI il rollback è simmetrico:

VBoxManage modifyvm "NOME_VM" --nested-hw-virt off

Se hai cambiato anche componenti dell’host per liberare l’hypervisor, il rollback deve includere il ripristino di Hyper-V, WSL2 o delle policy di sicurezza che erano state modificate. Qui il blast radius non è la singola VM, ma l’intero host e le sue dipendenze di sviluppo. Per questo conviene annotare prima cosa hai disattivato, con quale comando o quale toggle UI, e in che ordine lo riattivi.

Assunzione operativa: se il nested non funziona dopo l’abilitazione in VirtualBox, il problema è quasi sempre nell’host o nel firmware, non nella guest.

In pratica, la strada più pulita è trattare il nested VTX/AMD-V come una capability dell’intera catena, non come una proprietà della sola VM. Quando l’host è coerente, la configurazione è semplice; quando l’host è ibrido o sovraccarico di layer di virtualizzazione, la diagnosi richiede metodo e qualche verifica in più, ma resta comunque risolvibile senza interventi distruttivi.