Home     Documentation       VM-Sickbay        MOA        News        About      

 



VMDK Handbook - Snapshots

              by Ulli Hankeln

In emergencies visit    


back to Table of Content


This chapter is about snapshots and how to manage them.

For a list of the content see





 

 

YES
Most of the times you will hear a NO when you ask if you can recover data when all that is left is a *-delta.vmdk.
But this is not the full story.
You can actually recover data if you
- recreate a basedisk from scratch
- attach your orphaned snapshot to the new basedisk
- mount the disk and use recovery tools

This is pretty advanced work and requires very detailed information about
the way the original - now missing - basedisk was setup.

The involved procedures are very time consuming and it is easy to do it wrong.
Anyway - this is too advanced to be explained here in a few words.
If you want me look into your special case contact me

<<<


Translating VMware-Snapshotmanager button-names to common sense ...

 

What happens when you take a snapshot ?

You already know the term: snapshot - it usually means something like: take a photo in the middle of an action ...
Imagine you watch your little daughter climbing up a ladder - on step 5 she falls down - and in the precise moment she falls you take a photo. Wow - you now have a photo that shows your little daughter flying in the air.
You can show this snapshot to all her aunts and uncles ;-)
Lets get serious again. Does the photo matter ?
Nope - the moment of the snapshot is the breakpoint between to actions:
- climb up the ladder
- fall down.
In VMware-reality you can go back to the snapshot.
Actually you can go back to the end of the "climb ladder action" and have a second trial for the "fall down action".
This time dont stare at her - run ...

With VMware these actions are just files.

A virtual machine writes into a vmdk.
So what does "take a snapshot" mean ?
Very simple: finish the current vmdk and write into a new one.
Full stop - that's all.


finish current vmdk/redo-log keep current REDO-log keep
discard current REDO-log discard
merge current REDO-log with parent merge
start to write into a new vmdk/redo-log start new REDO-log
append
start new REDO-log
(append to selected parent)

append to selected


We got three ways to finalize the current vmdk and two ways to start a new one.
This adds up to some nice variants of combining our options.
See your self

VMware button label fileoperation simplified description
(imagine you are an author
and write a book)
     
Take Snapshot close and keep current REDO-log
start new REDO-log
finish current chapter
start a new chapter
Revert to Snapshot
(special case of Goto)
discard current REDO-log
start new REDO-log
restart last chapter
Delete merge current REDO-log with parent
start new REDO-log
define last chapter as good and keep it
start a new chapter
Goto discard current REDO-log
start new REDO-log
(append to selected parent)
discard last chapter
start over from chapter X
keep all different versions
     
Linked Clone start new REDO-log
(append to selected parent)
use with a new VM (vmx-file)
start a different version of the book using
the first X chapters of the main version
Full Clone merge current branch into a copy in a new dir
use with a new VM (vmx-file)
copy the complete book and work on the copy
keep the original as it is
     
a disk in
non-persistent mode
start new REDO-log
discard it at next exit
doesn't matter what you write
you will discard this chapter anyway

 

 


<<<


 

You can create a makeshift snapshot yourself with very simple tools.
Workstation will complain - it tells you that the snapshot must be repaired.
But in this case it does not matter because it is absolutely blank.
At first usage the makeshift file will be transformed in a "correct" snapshot vmdk.

Create a blank file - size does not really matter - it just should be large enough.
(need to make a list of recommended size - related to the nominal size of the parent)

fsz blabla-000001.vmdk 3000000


Next inject the "magic" first sector - you can download a copy here : monolithicSparse-snapshot-magic.bin


dsfi blabla-000001.vmdk 0 512 monolithicSparse-snapshot-magic.bin

 

Finally create a description - use the example and adjust parentfilename hint and the extent description.
Fill the end of the file with some spaces - so that the file is at least 1024 bytes long - then store it as description.txt
Then inject it with


dsfi blabla-000001.vmdk 512 1024 description.txt

 

 

 

<<<



Orphaned snapshots are snapshots that are not part of an existing snapshot-chain.
This should never happen - but in some cases ....

- unwise user action some time ago
- Workstation or ESX crash
- host OS crash or power-failure
- running out of diskspace during a snapshot action
- misconfigured or buggy behaviour of VMware tools like VCB or VDR
- misconfigured or buggy behaviour of third party backup tools - especially for ESX and ESXi

It is not trivial to check if a snapshot is orphaned for several reasons
- looking at the snapshot number in the filename is unreliable
- looking at the vmsd file is unreliable
- looking at the filename hint in the vmx-file only references the last used one at the end of the chain
- a snapshot maybe used by a VM in a different directory
- a snapshot maybe part of a linked clone in a different directory
- a snapshot may be the only part of a a separete branch in the snapshot-tree

To be absolutely sure if this snapshot is orphaned and so can be deleted we have to check if it is referenced
by any of the other vmdk-descriptions found in the same directory.
In case any other vmdk references the snapshot it may be part of one branch of the tree.
In case the snapshot is a direct child of the basedisk it may be a valid separate branch all by itself.
In case the CID or parentCID of the snapshot are referenced by any other vmdk it may be a required snapshot even if the parentfile name hints don't match.

What is the size of the snapshot file ?
The larger it is the longer it has been in use - the more valuable data may be stored in it.
Even If it is very small it may have never been used but it also may contain a single file - maybe just THE important one.

Long story short: you have to make an educated guess after analysing the other vmdks in the same directory.

Automated scripts that check for orphaned snapshots are only trustworthy if you can rule out user-mistakes.


-




<<<



Can I use ESX-snapshots in Workstation ?

YES
On recent Workstation like 6.5.3 you can use native ESX 4 snapshots in a Workstation VM without having to edit
the description first.
It is also possible to copy that snapshot back to ESX and continue to use it there.

Practical use:
patch ESX VMs "offline" on Workstation without the need to transfer large files

It is easy to do this wrong so I recommend this for experienced users only


<<<


 

Taking a snapshot means adding a new redolog to an existing regular vmdk or snapshot-chain.
In the vmx-file the added snapshot will then be referenced as
scsi0:0.filename = "myVM-00000*.vmdk"
and a new vmdk named "myVM-00000*.vmdk" will appear in the VM's directory.

To create a linked clone all we have to do is make a copy of the new snapshot, put it into a new directory
and create a new vmx-file for this vmdk.

Here are some older howtos I wrote for this:

very old guide showing how to do this with Ken Katos vdk.exe

this one is written in german - deutsch sprachige Anleitung

how to create linked clones on ESX4i without VirtualCenter

<<<

<<<