Due settimane fa ho passato due giorni di inferno, di quelli durante i quali sudi freddo, fumi due pacchetti di sigarette, ma dai quali esci contento di aver “salvato il mondo” e soprattutto aver veramente imparato qualcosa.

Scenario: un sistema iscsi contiene circa 12 VM che vengono avviate da due nodi ESXi. Ambiente classico per piccole aziende. Un bel giorno un tecnico della manutenzione pensa bene di tirar giù un paio di differenziali per alcuni lavori di pochi minuti, tra cui (non chiedetemi perchè) quello con su scritto “armadio server”. L’armadio stesso è in un angolo del capannone, e il rumore è sovrastato dalle presse. Ovvio quindi che l’allarme dell’ups non viene avvertito, e nonostante abbia circa 1 ora di autonomia, esaurisce completamente la carica, tirando giù in malo modo gli hosts, lo storage e le VM.

Io stavo rientrando dal mare, erano le due di pomeriggio e mi arriva la telefonata che solitamente non si vuole ricevere. Vabbeh, arrivo a casa, scarico giusto le valigie e vado a vedere. Pian piano riaccendo tutto, verifico i vari sistemi, e quasi tutte le VM nonostante tutto ripartono senza grossi patemi, solo qualche checkdisk in più durante i boot. Dicevo quasi tutte…

C’è sempre in ogni realtà quel particolare server che “manda avanti l’azienda”. Nel nostro caso era una VM windows 2000 server con installato Mago, un software gestionale. Ovviamente qual’è l’unica VM che no ne voleva sapere di ripartire? Ecco, quella…

L’errore era dovuto a un file di avvio corrotto, 2000 server è sempre stato delicato da questo punto di vista. Dato che c’era già l’idea di rifarlo con windows 2003 R2 abbiamo pensato di approfittarne, estrarre il database sql e reinstallarlo su una nuova VM.

Il metodo più semplice in questi casi è montare il disco vmdk come slave di un’altra VM windows, come si faceva anni fa nel mondo fisico, solo più veloce e semplice. Ho provveduto quindi a connettere il disco a una VM xp. Immaginerete la sorpresa nel vedere le date di ultima modifica dei dati a marzo invece che a giugno!!!!

Cosa è successo? Quello che leggerete è il sunto di un giorno di lavoro.

Vsphere client mostra nel datastore browser i file puntatori dei dischi vmdk ma non i delta file che sono stati generati dalle snapshot. Vi porta pertanto a montare non l’ultima versione del disco in questione, ma la prima, con tutto quello che ne consegue. E’ importante quindi per effettuare questi lavori utilizzare direttamente la console (locale o via ssh) in modo da avere visibilità di tutti i files coinvolti.

Quando si crea una snapshot, il disco originale server.vmdk viene congelato e le nuove scritture vengono registrate nel nuovo file server-000001.vmdk. Questi files però nel file system sono in realtà dei puntatori di pochi kb comodamente editabili con VI. I file veri e propri sono 4:

server-flat.vmdk, il disco vero e proprio, con dimensione di svariati Gb in base a come l'avete creato

server.vmdk, pochi kb di testo che descrivono il file server-flat.vmdk e altri parametri

server-000001-delta.vmdk, il nuovo disco su cui vengono scritte le modifiche

server-000001.vmdk, il file di testo che descrive il delta file

Il problema quindi è stato che montando server.vmdk, abbiamo in realtà connesso un disco che era fermo alla data di esecuzione della snapshot. Nel nostro caso l’ultima versione del database era infatti contenuta nella snapshot. Orbene direte voi, basta connettere il disco snapshot. NO!

Il problema nasce coi valori CID, ed è la parte più importante da comprendere.

Se editate uno qualsiasi dei file descrittori, troverete due righe che ci interessano:

CID: xxxxxxxx

parentCID: xxxxxxxx

parentFileNameHint="server.vmdk"

Il CID è un valore esadecimale che viene cambiato da ESX ogni volta che un disco viene avviato da una virtual machine. Seguendo le varie snapshots, si può vedere come esiste una vera e propria catena di questi valori, dove ogni snapshot possiede un suo CID e viene inoltre referenziata al CID del disco padre, sia che esso sia un’altra snapshot precedente o direttamente il disco padre. Il valore parentCID del disco padre è sempre ffffffff e ovviamente non possiede il campo parentFileNameHist

Capite quindi che avviare un disco padre direttamente non solo impedisce di vedere le modifiche contenute nelle snapshots, ma rompe anche la catena CID.

Dobbiamo quindi fermare tutto, e andare a editare via riga di comando i vari descrittori dei dischi, in modo da ricreare completamente la catena delle snapshots, su su fino al disco padre.

Questa è la prima parte. Non avrete modo come detto di montare la snapshot dal datastore browser. Potete quindi procedere così:

– montate nella VM il disco padre che vi viene mostrato dal datastore browser e salvate la modifica

– NON avviate la VM

– editate da riga di comando il file vmx e cercate la riga che descrive la connessione al disco.Troverete il riferimento al disco “server.vmdk”. Editatelo e metteteci invece “server-000001.vmdk” .

In questo modo la VM che avete usato come supporto per avviare il disco slave farà partire il disco all’ultima versione di snapshot e non alla versione vecchia di mesi.

Cosa abbiamo imparato da questa disavventura? Ovviamente l’importanza dei valori CID nel buon funzionamento delle snapshots, ma anche la potenziale pericolosità del datastore browser. Sempre meglio usare direttamente la shell per essere sicuri di avere una vista corretta dei file esistenti.