Non spostate quella VM

Da parecchi anni ormai, nonostante gli alti e bassi di VMware prima e Broadcom dopo in termini di licenza d’uso gratuita, uso con profitto ESXi sul mio NUC basato su Ryzen con i suoi 12 core e 64GB di RAM; questo ambiente mi serve per far girare il mio desktop Windows di riferimento, un paio di cluster Kubernetes, una toolchain (Gitea, Drone, Nexus Repository Manager) per gestire i miei progetti OSS quando Github Actions non basta e tanti altri gingilli.

Il prodotto semplicemente funziona. Come storage esterno, perché non ho voglia di perdere dati, uso una NAS QNAP e due volumi, uno iSCSI formattato VMFS6 ed due NFS e devo dire che in generale le performance NFS sono accettabili – se non superiori – ma soprattutto l’NFS mi permette di fare una cosa molto semplice: vedere i miei file se ho bisogno di fare operazioni sconsiderate come quella di oggi.

---

Per motivi che ora non sto a raccontare, ho sempre avuto tre volumi (due NFS e uno iSCSI) e mi trovo costretto a distruggere un volume NFS, quello che contiene una sola VM, il desktop Windows con (lo scoprirò dopo, mea culpa) uno snapshot di 43GB maturato dopo il test di un aggiornamento dell’OS… snapshot in uso e mai cancellato. Non ho mai avuto intenzione di fare un rollback, ma ora è li.

Forse non tutti sanno che… ESXi usa due formati differenti per lo snapshot; su NFS usa un delta disk e su VMFS il vmfssparse format. Grazie, e ora che lo so?

Bene, per “accellerare le operazioni” ed anche perché ESXi non ha la funzionalità di “spostamento di una VM” su disco, ne a freddo ne a caldo, ho deciso di fare browse nel VMFS e chiedere lo spostamento dell’intera folder della VM, dal volume NFS a quello VMFS perché avevo più spazio a disposizione per farlo.

Finita l’operazione, che ha richiesto un po’ di tempo visto che la VM era costituita da un disco da 70GB più uno snapshot di 43GB, ho ri-registrato la VM, premuto “Power on” e… semplicemente non è partita dicendo che manca il disco <nomevm>-000002.vmdk che è poi il disco contenente snapshot.

Una volta scoperto che avevo uno snapshot ho detto “ah si? ma avviamo la VM senza snapshot” creando una nuova VM e agganciando il disco padre della snap. Ecco, anche se la storia vi anticipo che è finita bene… non fatelo, nemmeno sotto tortura.

Da li scopro che la VM è abbastanza indietro con le configurazione e quindi la snapshot è fondamentale che funzioni. Incontro quindi qualche articolo sull’argomento (e facendo una snapshot della nuova VM verifico personalmente la situazione) che parla appunto del differente formato e mi consiglia una linea di comando abbastanza interessante (che alla fine userò) per consolidare a freddo una snapshot in un nuovo disco VMDK, così da preservare i file originali e non giocare con la GUI e con le VM esistenti:

vmkfstools -i w11master-000002.vmdk w11master-new.vmdk -d thin

Nelle condizioni migliori w11master-00002.vmdk contiene il riferimento agli altri snap e il disco master e genera un nuovo disco già consolidato chiamato w11master-new.vmdk. Nelle condizioni peggiori vi dice che il formato del disco è … non supportato:

DiskLib_Check() failed for source disk The specified feature is not supported by this version (24).

Il che già ci può gettare nel panico più totale. Scoperto l’arcano per cui uno snapshot su VMFS è diverso da uno snapshot su NFS, ho quindi ri-spostato la cartella nel filesystem NFS rimanente per poter riprovare il comando vmfstools con un nuovo risultato:

Failed to open 'w11master-000002.vmdk': The parent virtual disk has been modified since the child was created.

Bravo, perché? Perchè io il parent disk l’ho avviato per fare un test e quindi ha cambiato ID. Ora, qui entriamo nel territorio della probabilistica, perché riagganciare uno snapshot ad un parent disk modificato può portare a risultati non predicibili. Il disco di snapshot ha un riferimento al parent nel file contenente i metadati:

# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=7f0210dc
parentCID=938026ac
createType="vmfsSparse"
parentFileNameHint="w11master.vmdk"

Quello che si può fare è prendere il parent disk (w11master.vmdk), recuperare il suo CID e riportarlo nella snapshot come parentCID e poi sperare… Rilanciare vmkfstools che comunque non fallirà, a lui della consistenza dei blocchi modificati interessa fino ad un certo punto, ed al termine riaccendere la VM.

Risultato? Ho di nuovo la mia macchine Windows 11 accesa, funzionante, con tutti gli aggiornamenti di sicurezza installati nel tempo e i (pochi) dati che vi risedevano, perché tutti i dati in verità sono su NAS tranne alcuni sviluppi che Vantage Design Center salva localemente e che io backuppo ogni tanto su GIT.

Tutto è bene quel che finisce… ma la prossima volta che volete spostare una VM a freddo, controllate bene quello che state facendo!