1 21/10/2026 10 min

Android x86 in macchina virtuale: cosa funziona davvero

Se l’obiettivo è provare Android x86 senza toccare un dispositivo fisico, VirtualBox e VMware sono entrambi validi. La differenza pratica non è tanto nell’installazione del sistema quanto nella qualità dell’hardware virtuale che gli presenti: controller disco, accelerazione grafica, rete e gestione dell’input. Android x86 è abbastanza tollerante, ma se la VM è configurata male ti ritrovi con schermo nero, cursor lag, boot infinito o una rete che sembra viva ma non risolve nulla.

La strada più pulita è usare una ISO recente di Android x86 o di un progetto compatibile per architettura x86_64, creare una VM nuova, assegnare risorse moderate e installare su disco virtuale dedicato. Non serve gonfiare CPU e RAM oltre misura: per test e uso leggero 2 vCPU e 2 o 4 GB di RAM sono spesso sufficienti. Se vuoi un ambiente più reattivo, il punto non è “mettere più tutto”, ma evitare colli di bottiglia inutili nel layer virtuale.

Prerequisiti realistici prima di partire

Prima di creare la VM verifica tre cose: supporto alla virtualizzazione nel BIOS/UEFI, spazio disco libero e ISO corretta. Senza VT-x/AMD-V attivo, i tempi di boot peggiorano e su alcune configurazioni l’esperienza diventa inutilizzabile. Su host Linux, Windows o macOS il controllo cambia poco: l’importante è che il hypervisor possa esporre un ambiente x86 abbastanza standard.

Se hai dubbi sulla ISO, controlla architettura e checksum. Una ISO sbagliata o corrotta ti fa perdere tempo in debug inutile, soprattutto quando il problema sembra “Android non parte” ma in realtà il supporto di boot è danneggiato.

Controllo rapido su Linux host:

egrep -c '(vmx|svm)' /proc/cpuinfo

Se il risultato è maggiore di zero, il processore espone le estensioni di virtualizzazione. Se è zero, non significa per forza che non siano presenti, ma spesso indica che sono disabilitate nel firmware. In quel caso la correzione è nel BIOS/UEFI, non nella VM.

VirtualBox: configurazione che evita i problemi più comuni

VirtualBox resta la scelta più comoda per chi vuole una procedura lineare e una GUI molto chiara. Crea una nuova VM con tipo Linux e versione Other Linux (64-bit) o equivalente. Se la versione Android x86 è a 32 bit, usa la variante coerente con la ISO, ma oggi conviene quasi sempre puntare al 64 bit quando disponibile.

Impostazioni consigliate di base:

  • RAM: 2048 MB minimo, 4096 MB se hai margine.
  • CPU: 2 core come base, 4 solo se l’host non soffre.
  • Disco: 16–32 GB dinamico, controller SATA o virtio se supportato.
  • Grafica: memoria video elevata e accelerazione 3D da testare caso per caso.
  • Rete: NAT per partire, bridge solo se ti serve visibilità diretta in LAN.

Il punto critico in VirtualBox è spesso il controller video. Android x86 non gradisce tutte le combinazioni possibili e alcune versioni mostrano glitch grafici o rimangono su uno schermo nero dopo il boot. Se succede, la prima prova sensata è disattivare l’accelerazione 3D e riprovare. Se il problema persiste, cambia controller grafico o abbassa l’ambizione: meglio avere un desktop funzionale che una grafica teoricamente più veloce ma inutilizzabile.

Creazione da CLI, utile se vuoi ripetibilità:

VBoxManage createvm --name Android_x86 --ostype Linux_64 --register
VBoxManage modifyvm Android_x86 --memory 4096 --cpus 2 --vram 128 --graphicscontroller vmsvga --nic1 nat
VBoxManage createmedium disk --filename "$HOME/VirtualBox VMs/Android_x86/Android_x86.vdi" --size 20000
VBoxManage storagectl Android_x86 --name SATA --add sata --controller IntelAhci
VBoxManage storageattach Android_x86 --storagectl SATA --port 0 --device 0 --type hdd --medium "$HOME/VirtualBox VMs/Android_x86/Android_x86.vdi"
VBoxManage storageattach Android_x86 --storagectl SATA --port 1 --device 0 --type dvddrive --medium /percorso/android-x86.iso

Questi comandi non installano nulla da soli: preparano solo la VM. Se li usi, il vantaggio è che puoi replicare la stessa configurazione su più host senza dipendere da click manuali. Prima di avviare, controlla che l’ISO sia agganciata davvero e che il disco virtuale sia nel controller corretto.

VMware: quando conviene e cosa cambiare rispetto a VirtualBox

VMware Workstation o Player tende a essere più indulgente con alcune combinazioni video e spesso offre un’esperienza più fluida sul desktop di Android x86. In pratica, se hai avuto problemi di grafica in VirtualBox, VMware è un buon piano B. La logica di installazione è identica: nuova VM, ISO montata come unità ottica, disco virtuale dedicato e avvio dal supporto di installazione.

Impostazioni ragionevoli in VMware:

  1. Scegli Linux come guest e una variante coerente con l’ISO.
  2. Assegna 2 vCPU e 2 o 4 GB di RAM.
  3. Usa un disco virtuale singolo e semplice, senza complicare con controller esotici.
  4. Lascia la rete in NAT per il primo boot, poi valuta bridge se ti serve un IP visibile in LAN.
  5. Se la UI è lenta, verifica le impostazioni di grafica prima di aumentare le risorse.

In VMware il comportamento della tastiera e del mouse di solito è meno capriccioso, ma non dare per scontato che tutte le risoluzioni siano subito corrette. Android x86 può partire con una risoluzione conservativa e adattarsi male al resize della finestra. Se hai un display piccolo, conviene abilitare una modalità a schermo intero solo dopo aver verificato che input e rendering siano stabili.

Avvio dell’installer e scelta del disco

All’avvio della ISO comparirà un menu di boot. La voce da usare dipende dalla release, ma in genere c’è un’opzione per avviare il sistema live e una per l’installazione. Se il boot grafico fallisce, prova la modalità testuale o una variante con parametri più conservativi. In ambiente virtuale, il problema non è quasi mai “Android non supporta il tuo PC”, ma un compromesso sbagliato tra video, ACPI e controller disco.

Quando l’installer ti chiede dove installare, seleziona il disco virtuale che hai creato. Se il disco è vuoto, dovrai creare una partizione e formattarla. La scelta tipica è ext4, che è la soluzione più lineare per questo scenario. Se l’installer propone anche il bootloader, accettalo: senza GRUB o equivalente rischi di dover rientrare nella live ogni volta.

Flusso pratico tipico:

  1. Seleziona Installation.
  2. Scegli il disco virtuale, non l’ISO.
  3. Crea una partizione primaria se il disco è vuoto.
  4. Formatta in ext4.
  5. Installa il bootloader quando richiesto.
  6. Conferma la scrittura dei cambiamenti.

Se l’installer segnala problemi con il bootloader, non ignorarli. Un’installazione che sembra completata ma non parte al riavvio è spesso il risultato di un passaggio saltato nel setup del boot. In quel caso, il fix non è reinstallare tutto a caso: va verificata la tabella partizioni, la presenza del bootloader e l’ordine di boot della VM.

Persistenza: come non perdere tutto al riavvio

Uno degli errori più frequenti è avviare Android x86 in modalità live e poi stupirsi perché al reboot non resta nulla. La persistenza non è automatica: va installato sul disco virtuale, non solo eseguito da ISO. Se vuoi test veloci senza installazione, va bene, ma devi accettare che ogni modifica sparisca alla chiusura della VM.

Se invece vuoi un ambiente stabile, il disco virtuale deve essere parte integrante della VM. Per manutenzione, conviene anche fare snapshot prima di aggiornamenti o test rischiosi. Lo snapshot non sostituisce il backup, ma riduce il tempo di rollback in caso di boot failure o regressione grafica.

In pratica:

  • ISO sola = test usa e getta.
  • Disco virtuale installato = ambiente persistente.
  • Snapshot = punto di ritorno rapido, non archivio storico.

Rete, DNS e accesso ai servizi

La rete in NAT è la scelta meno problematica per iniziare. Ti permette di scaricare app, testare browser e usare i servizi online senza esporre la VM direttamente sulla LAN. Se ti serve che la VM sia raggiungibile da altri host, passa a bridge, ma solo dopo aver verificato che il driver di rete del guest sia stabile.

Un test rapido dentro Android, tramite terminale o app equivalente, dovrebbe confermare connettività e risoluzione DNS. Se la connessione c’è ma i nomi non si risolvono, il problema può stare nel DNS della VM, nel NAT del hypervisor o in una policy dell’host. Prima di inseguire bug improbabili, verifica la configurazione rete della VM e l’IP assegnato.

Se hai accesso a una shell, una verifica minima può essere questa:

ip addr
getprop net.dns1
ping -c 3 8.8.8.8
ping -c 3 google.com

Il primo comando mostra l’IP della VM, il secondo il DNS configurato, il terzo verifica la connettività IP e il quarto la risoluzione dei nomi. Se il ping verso un IP funziona ma il nome no, il problema è quasi sempre DNS e non routing.

Grafica, risoluzione e input: il trio che fa perdere più tempo

Android x86 in VM è molto sensibile al comportamento del driver video. Se la finestra è nera ma la VM sembra viva, il primo sospetto è il layer grafico, non il sistema operativo in sé. Disattivare temporaneamente accelerazione 3D, cambiare controller video o usare una risoluzione più conservativa risolve più spesso di quanto si pensi.

Anche mouse e tastiera possono comportarsi in modo strano. In alcuni casi il puntatore sembra “intrappolato” o il focus non viene acquisito correttamente. Qui il problema è del guest tools o dell’integrazione tra host e hypervisor. Se VMware o VirtualBox offrono strumenti aggiuntivi per il guest, vale la pena installarli solo dopo che il sistema è già partito bene: prima stabilisci il boot, poi rifinisci l’esperienza.

Se vuoi una regola pratica: quando compare un difetto visivo, tocca prima la configurazione video della VM, non Android. Quando compare un difetto di input, verifica integrazione e focus della finestra prima di cambiare le impostazioni interne del sistema.

Aggiornamenti e manutenzione senza rompere la VM

Una volta installato, Android x86 va trattato come un sistema da laboratorio: aggiornamenti con criterio, snapshot prima dei cambi importanti e attenzione alle versioni della ISO. Non è raro che una release nuova migliori il supporto hardware ma introduca regressioni su video o rete. Per questo conviene conservare il disco virtuale precedente o almeno un punto di ripristino.

Se la VM deve restare in uso nel tempo, tieni sotto controllo tre aspetti: spazio disco residuo, compatibilità del hypervisor e stabilità delle app installate. Quando il disco si avvicina alla saturazione, Android rallenta e alcune app si chiudono senza messaggi chiari. Non è un mistero: è il classico effetto collaterale di storage quasi pieno e cache che cresce più della capacità disponibile.

In ottica operativa, la manutenzione minima è questa:

  1. Verifica che la VM parta dopo ogni modifica del profilo hardware.
  2. Conserva una copia della configurazione della VM o esportala se il tool lo consente.
  3. Fai snapshot prima di cambiare versione di Android x86.
  4. Controlla che rete, display e storage restino stabili dopo ogni riavvio.

Errore tipico: installazione completata ma boot fallito

Questo è il punto in cui molti si fermano e rifanno tutto da zero. In realtà il boot fallito dopo installazione è quasi sempre riconducibile a una di queste cause: bootloader non installato, ordine di boot errato, controller disco incompatibile o ISO ancora montata al posto del disco virtuale. Prima di reinstallare, fai una verifica secca della VM.

Check rapido:

  • Il disco virtuale esiste e contiene partizione formattata.
  • L’unità ottica non sta forzando di nuovo il boot da ISO.
  • Il bootloader è stato installato nel disco corretto.
  • La VM usa un controller supportato dalla versione scelta.

Se il problema è il bootloader, in genere conviene rientrare nel menu di installazione e ripetere solo quel passaggio, non distruggere il disco. Se invece il disco è stato creato male, allora sì: meglio rifare la VM pulita che trascinarsi una configurazione incoerente.

Quando scegliere VirtualBox e quando VMware

VirtualBox è comodo per rapidità, portabilità e automazione di base. VMware spesso offre una resa grafica più gradevole e una gestione più robusta di certi guest. Se devi solo fare test, documentazione o prove applicative leggere, VirtualBox basta. Se invece ti interessa una sessione più fluida e hai già avuto problemi di compatibilità video, VMware merita la priorità.

La scelta non cambia la logica dell’installazione: cambia il livello di tolleranza verso gli errori di configurazione. In entrambi i casi, la regola resta la stessa: ISO giusta, disco virtuale pulito, risorse ragionevoli, rete semplice, snapshot prima dei cambi. Il resto viene dopo.

Se vuoi un criterio operativo molto pratico, usa VirtualBox per iterare velocemente e VMware quando vuoi stabilità visiva o hai bisogno di una esperienza più prevedibile sul desktop del guest.