I was reading Jason Boche’s blog on snapshots yesterday and noticed a misunderstanding. I tweeted Jason about this and his blog was updated in a sec. But I thought it might be handy to actually outline the basics again especially because during the VMTN Experts Podcast there was a huge discussion on snapshots. Unfortunately I could not join the call via audio so I decided to respond here.
While I was just checking my Google Reader I noticed that Eric Siebert beat me, he just released this blog that explains the basics of snapshots.
When a snapshot is created, the original disk becomes read-only, and a separate delta file is created that contains all the disk changes that are made thereafter. The delta file does not contain an ongoing history or transaction log of all the changes to data on the disk, it simply updates disk blocks as they are changed. If a particular block is changed it is written to the delta file, but if that same block is changed again later on the existing block is simply updated with the new data and a new block is not written to the delta file.
I want to add the following, which is an outtake of one of my articles from a couple of months ago:
Situation:
Snapshot 1 – 20GB
Snapshot 2 – 10GB
Snapshot 3 – 30GBWhen you choose “delete all” the following will happen:
- A helper snapshot is created which holds all changes
- Snapshot 2 will grow to 40GB at most
- Snapshot 1 will grow to 60GB at most
- Snapshot 1 will be committed to the original VMDK
- The helper is committed to the original
- All snapshot files are deleted
In other words: Snapshot 3 is merged into Snapshot 2, Snapshot 2 is merged into Snapshot 1, Snapshot 1 is merged into the original flat.vmdk and afterwards all snapshot files are deleted. This means that if you want to delete all snapshots at once you will need around 70GB of free disk-space in this particular situation and the size of the helper snapshot. So think twice before you press the “delete all” button.
So it comes down to the following:
- a single snapshot will not grow larger than it’ parent disk
- the disk files are not deleted until everything is consolidated
- a snapshot will grow in 16MB chunks and every time it grows the VMFS volume will be locked
Gabe was so kind to visualize the Snapshot “delete-all” process:
Thanks Eric for stealing my article 🙂
And for those who have got access to the VMworld presentations, check out TA14 – VMworld 2008 Europe.
Stirring up controversy is fun. I think I will do it more often.
Hey Duncan, Eric, and Jason,
Thanks again for such great articles. Something else I wanted to point out about snapshots that I just found out from my colleague, Jason Marchesano, is regarding snapshotting a VM when its vmdks are spread across multiple VMFS LUNs. Apparently if you snapshot a VM that has vmdks on different VMFS LUNs the snapshot delta file will be placed wherever the vmx file for the VM is located. The issue we have found with this is that VMFS LUNs are typically tiered so that an OS LUN may be on a slower performing disk than say a LUN used for SQL or Exchange. Given that you may have a SQL VM with its OS on an OS VMFS LUN and the SQL Data vmdk on a SQL/DATA VMFS LUN, if you take a snapshot of that VM you can have serious performance impact on the SQL database as well as corruption, in one of our customer’s cases. I haven’t had a chance to look at the VI4 implementation of snapshots, but I hope this is something VMware is taking a serious look at. Snapshots are a fantastic way to shoot yourself in the foot and there is really no good way to manage them currently from VMware (with the exception of PowerShell scripts of course). Thanks again, and keep up the good work!!
You are completely correct Lane. And this is indeed an issue when you setup the environment in this particular way. Luckily I don’t encounter this very often.