Skip to content
Luca Dell'Oca Principal Cloud Architect @Veeam
Virtual To The Core Virtual To The Core

Virtualization blog, the italian way.

  • Media
  • About me
Virtual To The Core
Virtual To The Core

Virtualization blog, the italian way.

Snapshots, delta files e CID

Luca Dell'Oca, June 15, 2010December 4, 2016

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.

Share this:

  • Click to share on X (Opens in new window) X
  • Click to share on Facebook (Opens in new window) Facebook
  • Click to share on LinkedIn (Opens in new window) LinkedIn
  • Click to email a link to a friend (Opens in new window) Email
  • Click to share on Tumblr (Opens in new window) Tumblr
  • Click to share on Pinterest (Opens in new window) Pinterest
  • Click to share on Reddit (Opens in new window) Reddit
  • Click to share on WhatsApp (Opens in new window) WhatsApp
  • Click to share on Pocket (Opens in new window) Pocket
Tecnologia snapshot

Post navigation

Previous post
Next post

Search

Sponsors

Latest Posts

  • Migrate WSL (Windows Subsystem for Linux) to a new computer
  • Pass keystrokes to a pfSense virtual machine to install it automatically
  • Automatically deploy pfSense with Terraform and Ansible
  • My Automated Lab project: #6 Create a S3 Bucket with Terraform
  • My Automated Lab project: #5 Deploy a Linux vSphere VM with Terraform and custom disks
©2025 Virtual To The Core | WordPress Theme by SuperbThemes
We use cookies to ensure that we give you the best experience on our website, and to collect anonymous data regarding navigations stats using 3rd party plugins; they all adhere to the EU Privacy Laws. If you continue to use this site we will assume that you are ok with it.OkNoPrivacy Policy