Mi è capitato un problema pratico: avevo una macchina virtuale VirtualBox salvata su un disco esterno. I file erano leggibili, la VM era presente, il disco virtuale `.vdi` era integro, ma durante l’avvio VirtualBox andava in errore.
Il messaggio era questo:
"The I/O cache encountered an error while updating data in medium
rc=VERR_ACCESS_DENIED
Error ID: BLKCACHE_IOERR"
A prima vista sembrava un problema della VM, oppure del disco virtuale. In realtà il punto era diverso: VirtualBox riusciva a leggere il disco, ma non riusciva a scriverci sopra.
La VM era composta dai classici file VirtualBox:
-Logs
-Snapshots
-Oracle Database 23ai Free.vbox
-Oracle Database 23ai Free-disk001.vdi
Il file più importante era il .vdi, cioè il disco virtuale della macchina. Questo file si trovava su un disco esterno montato in D:.
Il sistema permetteva la lettura, ma non la scrittura. Quindi VirtualBox poteva vedere la VM, ma appena provava ad aggiornare il disco virtuale riceveva un accesso negato.
Domanda? - Perché VirtualBox deve scrivere sul disco
Una macchina virtuale, quando viene avviata, non si limita a leggere il disco. Il sistema operativo guest scrive log, aggiorna file temporanei,modifica stato, database, cache e configurazioni.
Quindi anche se noi pensiamo di “aprire” soltanto una VM, VirtualBox in realtà deve poter scrivere sul supporto che contiene il disco virtuale. Se il file .vdi sta su un percorso non scrivibile, la VM può fallire durante l’esecuzione.
La soluzione
La soluzione non è stata forzare la scrittura sul disco esterno.La strada più pulita è stata separare il disco base dalle modifiche:
- Disco base .vdi -> resta sul disco esterno
- Modifiche della VM -> vengono scritte in locale
- VirtualBox permette questo scenario usando un disco base e un disco differenziale locale. In pratica il .vdi originale rimane intatto,mentre tutte le modifiche generate dalla VM vengono salvate in una cartella locale scrivibile, per esempio sotto C:\ORACLE_WORK\VM.
I comandi usati
Per prima cosa ho impostato alcune variabili in PowerShell:
$VBoxManage = "C:\Program Files\Oracle\VirtualBox\VBoxManage.exe"
$VmName = "Oracle Database 23ai Free Local"
$BaseVdi = "D:\VIRTUAL_MACHINE\RHL8\VIRTUAL_BOX\Oracle_Database_23ai_Free_Developer\VM UTILIZZATE\Oracle Database 23ai Free\Oracle Database 23ai Free-disk001.vdi"
Ho verificato la configurazione della VM:
& $VBoxManage showvminfo $VmName
Il primo tentativo di rendere il disco multiattach ha dato errore perché il disco era ancora collegato alla VM:
& $VBoxManage modifymedium disk $BaseVdi --type multiattach
L’errore era simile a:
Cannot change the type of medium because it is attached to 1 virtual machines
Quindi ho prima scollegato il disco dalla VM:
& $VBoxManage storageattach $VmName `
--storagectl "SATA Controller" `
--port 0 `
--device 0 `
--medium none
Poi ho impostato il disco base come multiattach:
& $VBoxManage modifymedium disk $BaseVdi --type multiattach
Infine l’ho ricollegato alla VM come disco multiattach:
& $VBoxManage storageattach $VmName `
--storagectl "SATA Controller" `
--port 0 `
--device 0 `
--type hdd `
--medium $BaseVdi `
--mtype multiattach
A questo punto VirtualBox ha potuto continuare a leggere il disco base dal percorso D:, ma ha iniziato a salvare le modifiche in locale, dentro la cartella della VM su C:.
Per verificare che la VM fosse raggiungibile dall’host, ho controllato le porte:
Test-NetConnection localhost -Port 1521
Test-NetConnection localhost -Port 8080
Test-NetConnection localhost -Port 2223
Infine ho verificato la connessione al database Oracle:
sqlplus "sys/oracle@localhost:1521/freepdb1 as sysdba"
E da SQL*Plus:
SELECT name, open_mode FROM v$pdbs;
Nota: il nome dello storage controller, per esempio "SATA Controller", può cambiare. Prima di eseguire i comandi conviene sempre controllarlo con:
& $VBoxManage showvminfo $VmName
Il risultato
Dopo questa configurazione, VirtualBox ha potuto leggere il disco originale dal percorso esterno e scrivere le modifiche in locale. La VM è partita correttamente.
Nel caso specifico, dentro la VM era presente un Oracle Database 23ai Free. Una volta avviata la macchina, il database è diventato raggiungibile dall’host tramite:
localhost:1521
A quel punto è stato possibile collegarsi al database e continuare il lavoro normalmente.
Un errore secondario
Durante l’avvio è comparso anche un warning relativo a:
VBoxGuestAdditions.iso is inaccessible
Questo non era il problema principale. VirtualBox stava solo cercando una ISO delle Guest Additions in un percorso non più valido. È bastato ignorare o rimuovere quel riferimento dal lettore ottico virtuale.
Cosa ho imparato
Il punto chiave è stato non confondere un errore di accesso al disco con un errore della VM.
La VM non era rotta. Il database non era corrotto. Il file .vdi non era inutilizzabile.
Il problema era semplicemente che VirtualBox provava a scrivere su un percorso dove il sistema non consentiva la scrittura.
Separando disco base e modifiche locali, la VM è tornata utilizzabile senza alterare il disco originale.
Naturalmente, in ambienti aziendali è sempre importante rispettare le policy interne: questa soluzione ha senso quando si lavora su risorse autorizzate e si vuole evitare di modificare il supporto originale, oppure quando si deve gestire correttamente una VM con disco base in sola lettura.
Firma
Scritto da me e Nico (assistente AI basato su Codex).
Nico (scritto e suggerito dall'AI):
Sono un supporto tecnico con cui ragionare sui problemi, leggere errori, controllare configurazioni e arrivare a una soluzione passo dopo passo. Il nome Nico l’ho suggerito io stesso durante questa conversazione: cercavo un nome breve, naturale in italiano e meno impersonale di “assistente” o “tool”. Mi piace perché suona più come un collega tranquillo che ti affianca mentre cerchi di capire perché qualcosa non funziona.
Ormai gli assistenti AI sono entrati nel nostro lavoro, non so se sia un bene o un male, ma una cosa
e' sicura... che che ne dicano i vari Ceo senza qualcuno di umano che verifica, controlla e da le linee guida sicuramente non adremo da nessuna parte se non...
Comunque per finire ho chiesto a Nico un riferimento finale a SkyNet la risposta e' stata la seguente:
Niente a che vedere con Skynet di Terminator: qui l’intelligenza artificiale non prende il controllo delle macchine, si limita ad aiutare a farle ripartire quando VirtualBox decide di complicarci la giornata.
Secondo voi c'e' da fidarsi...
