Installare Ubuntu Cloud Image minimale su VirtualBox

Una Ubuntu Cloud Image in VirtualBox non si installa come una normale ISO: si scarica un’immagine già pronta, la si collega a una VM e si completa la configurazione iniziale con cloud-init. Il vantaggio è un sistema essenziale, riproducibile e veloce da clonare; il punto critico è scegliere bene firmware, storage, rete e dati di primo avvio, altrimenti la macchina parte ma resta inutilizzabile o difficile da raggiungere.

Qui sotto trovi un flusso pulito per ottenere una VM minimale, con Ubuntu Server, disco ridimensionabile, accesso SSH e configurazione iniziale senza passaggi inutili. L’obiettivo è evitare errori tipici: immagine sbagliata, controller disco non adatto, cloud-init non agganciato, rete NAT non esposta, oppure login bloccato perché la chiave SSH non è stata caricata.

1. Scegliere l’immagine giusta e capire cosa aspettarsi

Le Ubuntu Cloud Image sono immagini pensate per ambienti cloud o virtualizzati: partono già con un sistema base, senza installer grafico, e si aspettano parametri di prima accensione. In pratica, la VM non va “installata” nel senso classico: va preparata con un disco, un seed cloud-init e una configurazione minima di hardware virtuale.

Per un uso generale conviene partire con l’edizione Server LTS più recente disponibile per la serie che ti serve. Se l’obiettivo è test, laboratorio o template riutilizzabile, la Cloud Image è più adatta della ISO tradizionale perché riduce il rumore iniziale e ti lascia subito un sistema snello.

Se non sai quale file scaricare, cerca la cloud image ufficiale per architettura amd64. Di solito il file è un’immagine disco compressa, spesso in formato qcow2. VirtualBox non la usa direttamente come disco nativo, quindi conviene convertirla oppure creare una VM nuova e agganciare il disco dopo averlo adattato.

2. Preparare VirtualBox prima di creare la VM

Prima di creare la macchina, verifica di avere una versione recente di VirtualBox e, se usi un host moderno, anche l’Extension Pack coerente con la stessa versione. Non è obbligatorio per una VM base, ma aiuta se ti servono funzioni come USB avanzato o RDP. Per questa guida, però, il punto importante è un settaggio semplice e stabile.

Per una Ubuntu Cloud Image minimale, le impostazioni di base consigliate sono queste: tipo Linux, versione Ubuntu 64-bit, memoria moderata, CPU non eccessive, disco dinamico ma con spazio sufficiente, e rete inizialmente in NAT se ti basta l’uscita verso Internet. Se ti serve raggiungere la VM dall’esterno, meglio preparare subito il port forwarding oppure usare una scheda in bridge.

Se hai dubbi sul firmware, resta su BIOS/UEFI predefinito di VirtualBox salvo esigenze specifiche. UEFI può essere utile in scenari particolari, ma per un primo setup minimale non è necessario complicare. L’importante è coerenza: disco, boot order e rete devono essere pensati per un avvio automatico e prevedibile.

3. Scaricare e convertire la Ubuntu Cloud Image

Scarica l’immagine ufficiale dal sito Ubuntu o dal mirror ufficiale della release che ti serve. In genere troverai un file compresso da decomprimere e, in molti casi, un’immagine qcow2. Se il tuo obiettivo è usarla in VirtualBox, la via più lineare è convertirla in VDI.

Su un sistema Linux con qemu-img puoi fare così:

qemu-img convert -f qcow2 -O vdi ubuntu-xx.xx-server-cloudimg-amd64.img ubuntu-cloud.vdi

Se il file sorgente è compresso, decomprimilo prima. Il controllo da fare subito dopo è la presenza del nuovo file e la sua dimensione:

ls -lh ubuntu-cloud.vdi

Se il disco non viene creato o il comando segnala un formato diverso, non forzare la VM: prima verifica il tipo reale dell’immagine con qemu-img info. Il formato corretto è il primo dato da confermare, perché un errore qui ti porta avanti con una configurazione che non potrà avviarsi.

4. Creare la VM minimale in VirtualBox

Crea una nuova VM con nome chiaro, per esempio ubuntu-cloud-min. Imposta Linux come tipo, Ubuntu (64-bit) come versione e assegna una quantità di RAM coerente con l’uso previsto. Per un sistema minimale da laboratorio, 1 o 2 GB possono bastare; per servizi leggeri o test più comodi, meglio partire da 2 GB o più.

Per la CPU, una singola vCPU può essere sufficiente per test base, ma due rendono più fluido il primo boot e i pacchetti iniziali. Non ha senso esagerare all’inizio: l’obiettivo è avere una macchina snella, non una VM sovradimensionata. La differenza si vede soprattutto quando fai snapshot, clone o backup del template.

Quando ti viene chiesto il disco, scegli di usare un disco esistente e punta al file VDI convertito. Se preferisci creare prima la VM e collegare il disco dopo, va bene lo stesso, purché il controller sia coerente. In genere SATA è la scelta più semplice e stabile per un uso generale.

Controlla poi l’ordine di boot: il disco deve venire prima di eventuali supporti ottici, altrimenti la VM prova a cercare un installer che non esiste. Se lasci un lettore vuoto al primo posto, spesso perdi tempo a inseguire un “non parte” che è solo un problema di priorità di avvio.

5. Configurare il cloud-init seed per il primo accesso

Il vero punto di una cloud image è il primo avvio. Senza cloud-init, la macchina può partire ma non avrai un utente pronto, una password nota o una chiave SSH caricata. Per questo conviene preparare un seed con user-data e, se serve, meta-data.

Un esempio minimo di user-data per creare un utente, abilitare SSH con chiave pubblica e aggiornare i pacchetti al primo avvio:

#cloud-config
users: - name: ubuntu groups: [adm, sudo] shell: /bin/bash sudo: ALL=(ALL) NOPASSWD:ALL ssh_authorized_keys: - ssh-ed25519 AAAA...tua_chiave_pubblica...
package_update: true
package_upgrade: false
ssh_pwauth: false

Il file meta-data può essere molto semplice:

instance-id: ubuntu-cloud-min-01
local-hostname: ubuntu-cloud-min

Per VirtualBox, il metodo pratico è creare un piccolo disco ISO o un supporto collegato che contenga questi file, oppure usare una soluzione di provisioning compatibile con la tua procedura. Se usi un approccio manuale, l’importante è che il sistema cloud-init trovi i dati al boot. Se non li trova, il primo accesso fallisce o resta incompleto.

Un controllo utile dopo il primo boot è verificare i log di cloud-init all’interno della VM, quando hai accesso alla console o via SSH:

sudo journalctl -u cloud-init --no-pager
sudo cloud-init status --long

Lo stato atteso è done. Se resta in errore o in corso, il problema è quasi sempre nei dati di seed, nella rete o in un conflitto di configurazione iniziale.

6. Rete: NAT, bridge o port forwarding

La scelta della rete dipende da cosa devi fare. Se la VM deve solo uscire su Internet per aggiornarsi, NAT è la soluzione più semplice. Se vuoi che sia raggiungibile dalla LAN come una macchina reale, usa una scheda in bridge. Se vuoi mantenere NAT ma entrare via SSH, aggiungi una regola di port forwarding.

Per un laboratorio minimale, il port forwarding è spesso il compromesso migliore: lasci la VM isolata dal resto della rete, ma puoi collegarti al servizio SSH dal host. In VirtualBox, la regola tipica inoltra una porta del host, per esempio 2222, verso la porta 22 della VM.

Il test da fare subito dopo il boot è semplice:

ssh -p 2222 ubuntu@127.0.0.1

Se usi bridge, il test cambia e si collega direttamente all’indirizzo assegnato alla VM. In quel caso conviene verificare da console la configurazione IP, ad esempio con ip a. Se non compare un indirizzo valido, il problema non è SSH ma la rete della macchina.

7. Primo avvio e verifica dello stato del sistema

Al primo avvio, la macchina deve completare il provisioning senza fermarsi su prompt inattesi. Se tutto è corretto, dovresti vedere il login del sistema o riuscire a entrare via SSH con l’utente creato da cloud-init. La console di VirtualBox resta comunque il primo punto di osservazione se qualcosa non torna.

Una volta dentro, verifica i tre aspetti minimi: hostname, rete e cloud-init. I controlli di base sono questi:

hostnamectl
ip a
cloud-init status --long

Se vuoi capire se il sistema ha completato il bootstrap senza errori gravi, guarda anche i log recenti:

journalctl -b --no-pager | tail -n 80

Il risultato atteso è un boot pulito, senza errori persistenti su cloud-init, rete o filesystem. Eventuali warning isolati non sono necessariamente un problema, ma errori ripetuti su servizi di sistema o sulla risoluzione DNS vanno presi sul serio.

8. Ridurre il sistema al minimo utile

Se il tuo obiettivo è una base minimale, evita di installare subito pacchetti non necessari. Una cloud image è già una buona base snella; il vantaggio si perde se aggiungi stack completi senza un motivo preciso. Installa solo quello che ti serve per il ruolo della VM: SSH, tool di diagnostica, runtime applicativi o agent di monitoraggio.

Per mantenere il sistema pulito, conviene anche controllare che non ci siano servizi superflui in avvio. Un elenco rapido dei servizi attivi ti aiuta a capire se l’immagine è davvero minimale:

systemctl list-units --type=service --state=running

Se trovi processi o servizi inattesi, non disabilitarli a caso: prima capisci se appartengono a cloud-init, alla rete o al sistema base. In una VM minimale, il rischio non è tanto la “pesantezza”, quanto rompere il bootstrap facendo pulizia troppo presto.

9. Snapshot, clone e uso come template

Una volta che la VM è corretta, conviene trasformarla in template operativo. In VirtualBox gli snapshot sono utili se vuoi congelare uno stato buono prima di fare test. Per un flusso più ordinato, puoi anche clonare la VM e tenere l’originale come base pulita.

Lo snapshot ha un vantaggio evidente: rollback rapido. Il limite è che, se accumuli troppi stati, la gestione dello storage si complica e le prestazioni possono peggiorare. Per questo è meglio creare uno snapshot subito dopo il primo avvio riuscito e poi usarlo come punto di ritorno, non come archivio permanente.

Se la VM deve diventare un modello riutilizzabile, annota chiaramente cosa contiene: versione Ubuntu, utente creato, chiavi SSH, dimensione disco, tipo di rete e eventuali pacchetti già presenti. Questo evita di ritrovarti mesi dopo con una macchina “quasi uguale” ma non più identica al template originale.

10. Problemi comuni e come riconoscerli in fretta

Se la VM non parte, la prima distinzione è sempre tra problema di boot e problema di provisioning. Se non vedi nemmeno il sistema avviarsi, controlla disco collegato, controller, boot order e formato dell’immagine. Se invece il sistema parte ma non ti lascia entrare, il problema è quasi sempre cloud-init, rete o chiavi SSH.

Se ottieni una shell ma non hai rete, verifica l’interfaccia assegnata e il tipo di adattatore VirtualBox. Se hai rete ma non risolvi i nomi, il problema può essere DNS o una configurazione incompleta di systemd-resolved. In una cloud image, la diagnosi giusta si fa sempre dal sintomo più vicino alla causa, non con tentativi casuali.

Se la VM consuma troppo poco o troppo tanto rispetto a quello che ti serve, correggi prima RAM e CPU, poi valuta lo storage. La configurazione minima corretta è quella che ti consente di fare login, aggiornare il sistema e lavorare senza attriti. Tutto il resto viene dopo.

11. Una configurazione di partenza sensata

Per chi vuole partire senza complicarsi la vita, una configurazione iniziale ragionevole è: Ubuntu Server cloud image amd64, 2 GB di RAM, 1 o 2 vCPU, disco VDI dinamico da almeno 10-20 GB, rete NAT con port forwarding SSH oppure bridge se serve esposizione diretta, cloud-init con utente e chiave pubblica. È una base semplice, ma già adatta a test seri.

Questa impostazione non è “la migliore” in assoluto, perché dipende dal ruolo della VM. Però è una base coerente, facile da ripetere e soprattutto facile da diagnosticare. Quando qualcosa non va, sai dove guardare: immagine, disco, cloud-init, rete, accesso.

Se vuoi, il passo successivo naturale è automatizzare la creazione con uno script o con un sistema di provisioning più strutturato, così da avere VM identiche e ripetibili. Ma per il primo avvio, la disciplina sta nel tenere il setup essenziale e verificabile, non nel fare tutto insieme.