Uno strumento presente da molto tempo in vSphere è quello che dà la capacità di acquisire degli snapshots di una macchina virtuale, sia spenta che accesa. Questa possibilità è fornita sia come strumento manuale, attraverso l'uso dello snapshot manager, sia come funzione utilizzata in modo trasparente durante operazioni specifiche sulle macchine virtuali, quali il backup o il cloning. Nonostante siano disponibili da molto tempo l'uso degli snapshots può creare qualche fraintendimento tanto che nell'attività formativa vale la pena perderci sempre qualche minuto.

Lo scopo di questo articolo è quello di fare una descrizione semplice ma efficace di questo meccanismo, in modo da metterne in luce le principali caratteristiche senza perdersi in particolari spesso poco utili.

Prima di tutto conviene dare una definizione di snapshot da cui partire. Questa può essere presa direttamente dalla documentazione ufficiale VMware che la riporta così: "A snapshot preserves the state and data of a virtual machine at a specific point in time".

L'elemento essenziale è senza dubbio il concetto di acquisizione dello stato della macchina virtuale ad un certo istante di tempo e la conseguente possibilità di ritornare a questa precisa condizione in qualunque momento (rollback). In seguito possiamo anche fare la scelta di non voler avere più la possibilità di tornare a quel particolare stato in quanto non più utile. Dunque le due operazioni che è possibile fare su uno snapshot dopo che lo si è creato sono il revert e il delete.

Un possibile fraintendimento sta proprio nell'interpretazione di questi due termini. Ad esempio l'operazione di revert è accompagnata necessariamente dalla perdita di dati anche se ciò non è affatto sottinteso dal termine. Il motivo è che se torno ad un istante precedente tutta la storia successiva della macchina virtuale viene necessariamente persa, a meno che non si crei un ulteriore snapshot prima del revert.

Al contrario, nonostante il suo significato letterale, il delete generalmente non si accompagna mai ad una cancellazione di dati bensì ad un consolidamento degli stessi in un unico file sul datastore. Qui il motivo è che il termine delete si riferisce in realtà solamente allo snapshot, cioè alla cancellazione della possibilità di tornare ad un preciso stato precedente (quello appunto garantito dallo snapshot) e non alla cancellazione di informazioni.

Per capire meglio questa logica conviene descrivere in modo essenziale (e non esattamente completo dal punto di vista del materiale creato nel datastore) i meccanismi di creazione e gestione degli snapshots.

Poichè lo scopo è quello di "fare una fotografia" dello stato di lavoro della macchina virtuale all'istante scelto, a cui devo poter ritornare in qualsiasi momento successivo, il sistema deve rispondere "congelando" il disco su cui la macchina virtuale lavora, cioè abbandonando in scrittura il file VMDK che stava utilizzando fino a quel momento e creandone un altro (delta file) su cui eseguire tutte le operazioni di scrittura da quel momento in poi. In figura 1 è mostrata sinteticamente la situazione.

In realtà lo stato complessivo di lavoro della macchina virtuale ad un certo istante è rappresentato dal contenuto del suo disco e da quello della sua memoria RAM. Se dunque l'intenzione è quello di costruire uno snapshot completo il sistema deve archiviare in un file dello storage anche l'immagine della memoria. Si tratta di un'opzione attivabile o meno ma ovviamente da essa dipende la possibilità di poter eseguire un revert mantenendo la macchina virtuale accesa. E' chiaro che da questo momento in poi il sistema userà entrambi i file della figura 1 per le operazioni di lettura e il solo delta file per le operazioni di scrittura. In particolare se dei blocchi di dati residenti nel file VMDK originale devono essere modificati, tali blocchi vengono prima copiati sul delta file e solo lì modificati.

Ovviamente nessuno ci impedisce in qualsiasi momento di acquisire un secondo snapshot (figura 2). E' chiaro che in questo caso il sistema dovrà rispondere a questa richiesta abbandonando in scrittura anche il delta file ed aprendo un secondo delta file ed eventualmente, se glielo abbiamo chiesto, anche un ulteriore file in cui scaricare il contenuto della memoria. Da questo momento in poi tutte le operazioni di scrittura dovranno essere eseguite sul secondo delta file con la logica già descritta mentre le operazioni di lettura necessiteranno di tutti i file creati (tranne quelli in cui è stata scaricata la memoria RAM che verranno riutilizzati solo nelle operazioni di revert). Questa operazione può essere reiterata quanto si vuole creando così una serie di punti nel tempo in cui poter ripristinare lo stato della macchina virtuale in corrispondenza dei quali avrò sullo storage una catena logica di delta file collegati tra loro fino al VMDK iniziale. Da notare che se faccio un'operazione di revert a qualche snapshot intermedio della catena e da questo comincio ad acquisire altri snapshot costruisco una vera e propria struttura ad albero che ha il VMDK originale come root.

Abbiamo già detto che una volta creato uno snapshot le due operazioni successive che è possibile eseguire sono il revert e il delete. Con il primo si intende far ritornare la macchina virtuale esattamente nello stato di lavoro corrispondente al momento dell'acquisizione dello snapshot, con il secondo si vuole invece cancellare lo snapshot, cioè negarsi da quel momento in poi la possibilità di poter ritornare a quello stato di lavoro. Per quello che è stato detto nel paragrafo precedente le due operazioni si possono descrivere come segue

1. revert - Tornare al momento dello snapshot significa azzerare il delta file che era stato creato al momento dell'acquisizione dello snapshot. Fisicamente significa creare un altro delta file vuoto da cui ripartire, mentre il vecchio potrebbe essere cancellato o "parcheggiato" (vedi paragrafo successivo). Se al momento di acquisizione dello snapshot si era scelto di scaricare in un file separato anche la memoria della macchina virtuale allora durante il revert questa viene ricaricata in RAM, in caso contrario la macchina virtuale viene spenta.

2. delete - Cancellare lo snapshot significa consolidare tutti i dati nel file VMDK originale (o nel delta file dello snapshot precedente, vedi paragrafo successivo). In tal modo non perdo nessun dato dello stato di lavoro corrente della macchina virtuale ma chiaramente perdo la possibilità di ritornare allo stato di lavoro definito da quello snapshot, e tale operazione è ovviamente irreversibile. Se si cancella uno snapshot "a valle" dello stato corrente, cioè se eseguo prima un revert ad uno stato precedente e quindi cancello lo stato successivo, il sistema banalmente cancella il delta file associato in quanto conterrà dati non utilizzati che non dovranno essere consolidati bensì semplicemente persi.

Proviamo a questo punto ad analizzare un esempio. Supponiamo di avere a disposizione una macchina virtuale sulla quale inizialmente non ci siano snapshots. Acquisiamo un primo snapshot (SNAP1) al tempo T1. Il sistema risponderà creando il delta file DELTA1. A questo punto installiamo un'applicativo qualunque (APP) sulla macchina virtuale e alla fine dell'installazione acquisiamo un secondo snapshot (SNAP2) al tempo T2, a cui il sistema farà corrispondere un nuovo delta file (DELTA2). Da questo punto in poi la macchina virtuale continua a lavorare regolarmente. Tutto il processo è illustrato in figura 3.

1. Revert a SNAP2 (figura 4) - questa operazione dal punto di vista logico significa far tornare lo stato della macchina virtuale a quello definito al tempo T2, cioè al momento immediatamente seguente al termine dell'installazione dell'applicativo. Dal punto di vista fisico è necessario cancellare il file DELTA2 che contiene la storia da T2 al momento in cui eravamo arrivati e definire un altro delta file (DELTA3) che "ricomincia" a far funzionare la macchina virtuale a partire da T2. E' chiaro che tutti i dati contenuti in DELTA2 vengono persi in modo irreversibile. Se avessimo voluto conservare la "storia" precedente (e quindi il file DELTA2) prima del revert avremmo dovuto acquisire uno snapshot (vedi punto 2).

2. Revert a SNAP1 (figura 5) - la differenza con il caso precedente è che si vuole fare un revert non all'ultimo snapshot ma ad uno snapshot intermedio, in tal caso devo mantenere la possibilità di tornare in avanti sull'ultimo snapshot. Quindi dal punto di vista logico vado all'istante T1, in cui non ho l'applicazione installata, con l'intenzione però di poter tornare avanti in un secondo momento su T2 in cui recupero l'applicazione (vedi punto 3). Dal punto di vista fisico devo cancellare il file DELTA2 in quanto non più utilizzabile (perdo i dati della storia da T2 in poi). Non devo invece cancellare il file DELTA1 poichè è esattamente quello che contiene la storia che sarà in grado di riportarmi all'istante T2 (è il file che contiene l'installazione dell'applicativo). Ovviamente non posso utilizzare il file DELTA2 nel momento in cui voglio ripristinare lo stato della macchina al tempo T1 quindi definisco un nuovo delta file dipendente direttamente dal VMDK iniziale (DELTA3).

3. Revert a SNAP2 da SNAP1 (figura 6) - se a partire dalla situazione finale del punto 2 vogliamo adesso tornare allo stato del sistema come definito dallo snapshot all'istante T2 devo cancellare il delta file DELTA3 che mi aveva permesso di tornare a SNAP1 e creare un altro delta file (DELTA2) dipendente questa volta da DELTA1 che proprio per questo motivo è stato conservato. In tal modo recupero l'installazione dell'applicazione e mi riposiziono sullo SNAP2 al tempo T2. I dati contenuti in DELTA3 vengono irrimediabilmente persi.

Da notare che se ripartiamo dalla situazione illustrata nella figura 5 e da qui acquisiamo un terzo snapshot (SNAP3) otterremmo una ramificazione temporale. Il sistema cioè non abbandona il file DELTA3 ma ne crea un altro (DELTA4) dipendente da esso. Se supponiamo di aver installato su DELTA3 una seconda applicazione (APP2) allora avremmo realizzato una macchina virtuale con una "doppia storia" a partire dall'istante T1, quella in cui abbiamo installato APP e quella in cui abbiamo installato APP2.

4. Delete dello SNAP1 (figura 7) - come già detto e come si vede chiaramente in figura 7 l'operazione di Delete non cancella di fatto nessun dato. La cancellazione è solo dell'elemento logico SNAP1 a cui il sistema risponde con un'operazione di consolidamento del file DELTA1 sul parent VMDK. A questo punto non sarà più possibile tornare all'istante di tempo T1 in cui l'applicazione APP non era stata ancora installata.

5. Delete dello SNAP2 (figura 8) - infine il Delete dell'elemento logico SNAP2 determina il consolidamento del file DELTA2 sul suo parent DELTA1 rendendo impossibile il ritorno all'istante T2 in cui APP era stata appena installata.

Supponiamo di stare di nuovo nella situazione illustrata dalla figura 5. Se a questo punto facciamo il Delete di SNAP2 il sistema non fa nessun tipo di consolidamento, invece cancellerà il file DELTA1 poichè non potrà essere più utilizzato (avrebbe senso farlo solo appendendo ad esso un delta file dello SNAP2 che ne continuerebbe in modo coerente la "storia").

In sistemi complessi non è sempre così facile associare ad effetti "strani" delle cause logiche ben precise. Qualche volta ci si riesce per situazioni del tutto fortuite, specialmente se gli effetti in cui ci imbattiamo non sono poi così gravi e il fatto di trascurarli, sebbene possa darci fastidio, non porta a conseguenze importanti.

Potrebbe capitare di notare durante la gestione delle nostre macchine virtuali che alcune di esse diano l'impressione di lavorare con due schede di rete. Questa impressione è indotta dal fatto che la scheda "Summary" del vSphere Client di Windows (ad oggi uno strumento amministrativo ufficialmente soppiantato dal vSphere Web Client ma ancora ampiamente utilizzato dagli amministratori) ci mostra il collegamento della macchina virtuale a due portgroup distinti (figura 9).

Verifichiamo che si tratta di un'impressione, o meglio di un'informazione sbagliata, andando nell'editor della macchina virtuale e verificando che la sua configurazione hardware ha una sola vNIC, associata ad uno dei due portgroup, quello su cui effettivamente sta lavorando. Un'ulteriore conferma di questo l'abbiamo quando andiamo a verificare i settaggi del sistema operativo guest. Quindi la presenza del secondo portgroup è totalmente ingiustificata ma non sembra ci sia un modo per eliminarla. Che sia impegnata in qualche modo da qualche componente del sistema operativo guest come succede ad esempio per gli ISO files con gli elementi di storage? Se si decide di sganciare la vNIC dal primo portgroup e agganciarla al secondo il problema scompare, nel senso che dal Summary scompare il primo portgroup. Ma se poi si ritorna indietro il problema si ripresenta tale e quale. Sembrerebbe che il secondo portgroup venga visualizzato comunque, sia se la vNIC lo aggancia sia se non lo fa. Il fatto, sebbene non abbia conseguenze gravi (anzi nessuna conseguenza), risulta essere piuttosto oscuro.

Fino a che un bel giorno non ci succede per caso di osservare che questa cosa bizzarra è scomparsa e realizziamo che l'ultima operazione che abbiamo fatto sulla macchina virtuale è stata un consolidamento di vecchi snapshots rimasti ingestiti e addirittura dimenticati. Una breve analisi e qualche ulteriore prova ce lo conferma. Infine, guidati dall'esperienza ricerchiamo e troviamo una documentazione ufficiale che ne riporta la descrizione (l'articolo di knowledge base numero 2020052 "Summary tab shows multiple network port groups that are not used by the virtual machine"). Nel descrivere le cause l'articolo recita così: "This issue occurs if a snapshot of the virtual machine is taken when it is connected to one of the listed port groups and is subsequently connected to another port group later. If the snapshot is not consolidated, the virtual machine continues to report as being connected to this portgroup because the virtual machine could theoretically revert to this portgroup connection if the virtual machine state in the snapshot is restored". Bene, siamo soddisfatti. Non serve granchè ai fini pratici ma abbiamo capito cosa succedeva e adesso sappiamo risolvere il problema se ci ricapita.

Tra l'altro questo semplice caso pratico ci insegna anche che la descrizione fatta in questo articolo non è del tutto completa in quanto è evidente che le modifiche incluse nello snapshot non sono solo quelle relative all'attività del sistema operativo guest sul disco e sulla memoria ma anche tutti gli eventuali settaggi e configurazioni della macchina virtuale e del suo virtual hardware, come ad esempio il cambiamento della connessione di rete.

Dall'analisi fatta in questo articolo si traggono facilmente poche ma importanti conclusioni sull'argomento:

1. Gli snapshots sono uno strumento veloce ed efficacie per tornare indietro da una configurazione sbagliata o da un'installazione che impatta negativamente sulle funzionalità del sistema. L'idea principale è quella di poter predisporre facilmente, a fronte di modifiche significative e pianificate di una macchina virtuale che si accompagnano ad un certo fattore di rischio, una procedura di rollback in grado di riportare il sistema al suo funzionamento originale.

2. Non ha alcun senso concepire gli snapshots su una macchina virtuale qualsiasi come una regolare attività di backup, basti pensare al fatto che tutto il materiale si troverà necessariamente nello stesso elemento di storage e sono tutti logicamente concatenati (ma questo non è certo l'unico motivo).

3. Non ha alcun senso mantenere degli snapshots a lungo per un sistema in produzione. L'operazione di revert è sempre completa, non può essere in alcun modo parziale. Tornare ad un istante molto indietro nel tempo è quasi sempre un'assurdità. Diverso il discorso per sistemi in sviluppo o in test, oppure per sistemi didattici o utilizzati come demo.

4. Far lavorare un sistema con una catena di snapshots mai consolidata porta inevitabilmente a due gravi conseguenze: occupazione incontrollata dello spazio di storage, degrado delle performance nelle operazioni di lettura e scrittura dei dati su disco.