1 26/05/2026 10 min

Preparare VirtualBox e l’immagine CentOS 8

Per installare CentOS 8 su VirtualBox conviene partire da un punto semplice: host aggiornato, VirtualBox installato correttamente e un file ISO verificato. Il problema più comune non è l’installazione in sé, ma un dettaglio banale che fa perdere tempo dopo il primo riavvio: ISO corrotta, rete configurata male, controller disco scelto senza criterio o risorse assegnate troppo strette per avviare l’ambiente grafico o anche solo il sistema base.

CentOS 8 è ormai fuori dal ciclo standard di vita, quindi la prima decisione tecnica non è “come installarlo”, ma quale ISO usare. Se ti serve un ambiente didattico o di test, verifica la disponibilità dell’immagine nel repository che stai usando e l’integrità del download. Se invece vuoi una base più attuale per compatibilità a lungo termine, valuta già in fase di progetto se conviene spostarsi su una derivata supportata o su un clone compatibile. Qui però il flusso resta quello classico: macchina virtuale, avvio da ISO, installazione, primo boot e controllo dei servizi essenziali.

Prima di aprire VirtualBox, prepara questi elementi: l’ISO di installazione, almeno 2 CPU virtuali se vuoi un’interfaccia usabile, 2 GB di RAM come minimo realistico per l’installer grafico, e uno storage virtuale da almeno 20 GB. Se prevedi di fare test con repository, compilazioni o pacchetti aggiuntivi, 30–40 GB è una scelta più serena.

Creare la VM con parametri sensati

Apri VirtualBox e crea una nuova macchina virtuale con nome descrittivo, per esempio CentOS8-lab. Il tipo va su Linux e la versione, se presente, su Red Hat (64-bit) oppure una variante equivalente a 64 bit. Non è un dettaglio cosmetico: VirtualBox usa quel profilo per impostare valori di default coerenti con il kernel Linux e con alcune ottimizzazioni del chipset virtuale.

Le scelte iniziali che fanno davvero differenza sono queste:

  • RAM: 2048 MB minimo, 3072 MB se vuoi installare anche ambiente grafico e lavorare senza rallentamenti evidenti.
  • CPU: 2 vCPU come base; 4 solo se l’host ha margine reale.
  • Disco: VDI dinamico va bene per il lab; fisso se vuoi prestazioni più prevedibili e spazio già riservato.
  • Controller: SATA per semplicità; NVMe solo se sai perché ti serve e il supporto del guest è coerente con la tua versione di VirtualBox.
  • Rete: NAT se vuoi solo uscire su Internet; bridge se la VM deve essere raggiungibile dalla LAN.

Se stai usando un host con poca RAM, evita il riflesso di “dare tutto alla VM”. Un sistema ospite sotto pressione degrada anche la VM: swap, latenza I/O e boot più lenti sono quasi sempre sintomo di oversubscription, non di CentOS in sé.

Configurare storage e firmware senza creare problemi inutili

Nel pannello Archiviazione, collega l’ISO al lettore ottico virtuale e assegna il disco virtuale al controller scelto. Per una installazione standard, un disco VDI dinamico da 25 GB è un buon compromesso. Se vuoi fare test che toccano database, log o container, alza la soglia. Il disco dinamico è comodo, ma non è magia: se l’host ha filesystem frammentato o poco spazio libero, l’espansione del file può diventare un collo di bottiglia.

Per il firmware, l’opzione BIOS classico è la più semplice. UEFI va bene se ti serve replicare un ambiente moderno o se stai verificando procedure specifiche, ma per un’installazione base non aggiunge vantaggi concreti. Se abiliti UEFI, fallo con consapevolezza: cambia il comportamento del bootloader e può complicare il recupero se non hai esperienza con la struttura delle partizioni e con grub2.

Una configurazione prudente per il primo setup è questa:

VM: CentOS8-lab
RAM: 2048-3072 MB
CPU: 2
Disk: 25 GB VDI dinamico
Controller disco: SATA
Boot: ISO ottica, poi disco
Rete: NAT per test, Bridge per accesso LAN

Avvio dell’installer e scelta delle opzioni iniziali

Avvia la VM dalla ISO. Nel menu iniziale scegli Install CentOS 8. Se lo schermo resta nero o l’avvio si blocca, la prima verifica non è “reinstallare tutto”, ma controllare tre cose: che l’ISO sia montata davvero, che la VM sia configurata per 64 bit e che l’accelerazione VT-x/AMD-V sia disponibile sull’host.

Durante il caricamento dell’installer, se vedi errori grafici o un’interfaccia che non si ridisegna bene, spesso basta cambiare il controller video o ridurre l’accelerazione 3D. In un lab Linux, la priorità è stabilità, non effetto grafico. La 3D è utile solo se devi testare software che ne fa uso.

Quando l’ambiente di installazione si apre, imposta subito lingua, tastiera e fuso orario. Il fuso orario è una di quelle cose che si sottovalutano finché non leggi log con timestamp sfasati o non ti trovi cron e certificati con tempi incoerenti rispetto all’ambiente host.

Partizionamento: semplice, leggibile, recuperabile

Per una VM di laboratorio, il partizionamento automatico va bene nella maggior parte dei casi. Se però vuoi imparare qualcosa di utile e non solo cliccare avanti, conviene definire manualmente uno schema minimo leggibile. La scelta più pratica è separare almeno / e /home, oppure / e /var se prevedi log o servizi che scrivono parecchio.

Un layout semplice e robusto può essere questo:

  • /boot: 1 GB
  • /: 15–18 GB
  • /home: resto dello spazio disponibile
  • swap: automatico o 1–2 GB, a seconda della RAM assegnata

Se non hai una ragione precisa per complicare le cose, evita LVM solo per abitudine. LVM è utile, ma in una VM didattica aggiunge un livello che ha senso solo se vuoi esercitarti con resize, snapshot logici o recovery. Per una prima installazione, la semplicità riduce gli errori e rende più facile capire dove sta il problema se qualcosa non parte.

Selezione dei pacchetti e primo avvio

Nella schermata dei software, la scelta dipende dall’obiettivo. Se vuoi un sistema minimale da usare via SSH, installa il profilo Minimal Install. Se invece ti serve una macchina con interfaccia grafica per prendere confidenza con la distribuzione, scegli un ambiente desktop coerente con le tue risorse. In una VM, però, il “più leggero possibile” è spesso la scelta più razionale: meno servizi, meno superfici di errore, meno memoria consumata.

Avvia l’installazione e attendi il completamento. Al termine, riavvia la VM e rimuovi la ISO dal lettore virtuale se non vuoi che riparta l’installer. Questo passaggio sembra banale, ma è uno dei classici motivi per cui chi installa per la prima volta pensa che il sistema sia “bloccato” in un loop di boot.

Dopo il reboot, accedi con l’utente creato durante l’installazione o come root se hai abilitato l’accesso diretto. Subito dopo il login, verifica lo stato base del sistema con comandi semplici:

uname -r
cat /etc/centos-release
ip a
systemctl --failed

Il risultato atteso è un kernel caricato correttamente, la release identificata, un’interfaccia di rete con IP assegnato e nessun servizio fallito nel primo avvio. Se systemctl --failed mostra unità in errore, non partire subito a disabilitare cose a caso: leggi prima il log della singola unità con journalctl -u nome-servizio.

Configurazione rete: NAT o bridge, ma con un obiettivo chiaro

La rete è il punto in cui molte installazioni sembrano riuscite ma poi non sono davvero utilizzabili. Con NAT la VM naviga e scarica pacchetti, ma dall’esterno non è raggiungibile a meno di configurare port forwarding. Con Bridge la VM entra nella LAN come un host separato e riceve un indirizzo dal DHCP della rete, quindi è comoda se devi fare SSH, test di servizi o simulare un server reale.

Per controllare rapidamente la connettività usa questi test:

ip route
ping -c 3 8.8.8.8
ping -c 3 google.com

Se il ping verso l’IP funziona ma quello verso il nome no, il problema è quasi sempre DNS, non rete. In quel caso verifica il contenuto di /etc/resolv.conf o la configurazione gestita da NetworkManager. Se invece non hai route predefinita, il problema è a monte: interfaccia, DHCP o modalità di rete di VirtualBox.

Primo hardening minimo senza trasformare il lab in un progetto infinito

Una volta che il sistema parte, applica un hardening minimo. Non serve trasformare la VM in un fortino, ma ha senso ridurre i rischi più grossolani. Aggiorna i pacchetti, verifica che SSH sia attivo solo se ti serve, e non lasciare servizi inutili esposti. Se la VM è in bridge, ricordati che da quel momento è visibile come qualsiasi altro host della rete.

Un ciclo ragionevole è questo:

  1. Aggiorna la cache e i pacchetti con il gestore disponibile.
  2. Verifica gli aggiornamenti critici e i repository configurati.
  3. Controlla i servizi in ascolto con ss -tulpn.
  4. Disabilita o rimuovi ciò che non ti serve nel lab.

Per l’audit minimo, il comando più utile è:

ss -tulpn
sudo systemctl list-unit-files --type=service --state=enabled

Il primo ti dice cosa ascolta davvero sulla VM; il secondo ti mostra cosa parte automaticamente. Se trovi servizi non necessari, la modifica va fatta con criterio e con un’idea di rollback. In una macchina di test il rollback è semplice: riabilitare il servizio con systemctl enable --now nome-servizio o ripristinare lo snapshot della VM se hai deciso di farne uno prima delle modifiche.

Snapshot e punto di ritorno: il vero vantaggio della virtualizzazione

Una VM ben gestita non si limita a “funzionare”: deve essere recuperabile in pochi minuti. Prima di fare modifiche più pesanti, crea uno snapshot della macchina. Non è un backup completo, ma è un ottimo punto di ritorno se stai testando kernel, rete, firewall o configurazioni del bootloader. La regola pratica è semplice: snapshot prima del cambiamento, verifica dopo il cambiamento, e pulizia degli snapshot vecchi quando hai confermato che tutto è stabile.

Se usi snapshot in modo seriale senza disciplina, il disco virtuale cresce e le prestazioni possono peggiorare. Quindi snapshot sì, ma con uso mirato. Se devi conservare uno stato affidabile per lungo tempo, meglio esportare la VM o fare un backup coerente dei file della macchina spenta.

Problemi tipici durante l’installazione e come leggerli subito

Se l’installer non parte, la causa è di solito una di queste: ISO sbagliata, virtualizzazione hardware disattivata, impostazioni 64 bit non disponibili o conflitto con altri hypervisor. Su host Windows, Hyper-V o protezioni equivalenti possono limitare VirtualBox; su host Linux, il problema può essere il modulo kernel o permessi mancanti. La diagnosi corretta parte sempre dal sintomo visibile, non da ipotesi generiche.

Se il sistema installato non ottiene rete, verifica l’interfaccia dall’interno e la modalità della scheda in VirtualBox. Se ottieni una schermata nera dopo il boot, prova a rimuovere l’installazione grafica pesante, controlla il controller video e, se serve, cambia il profilo della VM. Se il sistema si avvia ma è lentissimo, guarda prima l’host: CPU satura, RAM insufficiente o disco quasi pieno sono più frequenti di un problema “misterioso” di CentOS.

Impostazione finale per un lab pulito e ripetibile

La configurazione finale che funziona meglio, nella maggior parte dei casi, è quella che minimizza le variabili: una VM con risorse moderate, rete NAT se devi solo fare test locali, bridge se devi esporre servizi, disco dinamico ben dimensionato e snapshot usato con criterio. Dopo l’installazione, verifica kernel, rete, servizi e spazio disco. Se questi quattro punti sono in ordine, la VM è pronta per essere usata come base per Apache, Nginx, SSH, test di DNS o simulazioni di server Linux classici.

In pratica, il valore della procedura non sta solo nel “riuscire a installare CentOS 8”, ma nel costruire una macchina prevedibile: facile da clonare, facile da ripristinare e abbastanza pulita da non nascondere i problemi. È questo che rende VirtualBox utile in un contesto sysadmin: non la installazione in sé, ma la possibilità di ripetere il setup con risultati coerenti.

Se ti serve un ambiente da laboratorio davvero affidabile, documenta subito tre cose: versione dell’ISO, parametri della VM e modalità di rete. Sono i tre elementi che, quando qualcosa non torna, ti permettono di capire in pochi minuti se il problema è nel guest, nell’host o nella rete virtuale.