Having used drive imaging software for over a decade, I find it mind boggling that Virtual Machines can be snapshotted and restored in a matter of seconds, while drive imaging often takes hours.
I can snapshot a VM, reinstall to a different OS, then do a restore and somehow magically within seconds my old VM is back up perfectly in the state it was previously in.
How is this able to happen? What does the VM host actually do to the VM that makes this possible?
When you create a snapshot, all changes made on the initial virtual disk image are not actually made on the image itself, but they are written to a new (snapshot) disk file. This action is so fast because there is no need to copy whole virtual disk image, because it works on copy on write principle (only changed, i.e. written blocks are written to snapshot image). Note that snapshot image grows as you change more and more data on your original virtual disk image (which stays as it was on the moment you took the snapshot). It will most probably be much smaller than original image, but in the worst case it will be exactly the same size (if all blocks were changed).
There are two actions you can make with this new snapshot image:
All procedures described above also work for multiple snapshots. In that case original image may be one snapshot, and next snapshot may reference block on that (first) snapshot. This way you can have many snapshots you can discard or merge with ease.
With a snapshot, your virtualization software has to keep track of four things: CPU state, RAM, configuration (how many network cards in the VM?), and disk. I'm ignoring the first three things because they're not huge amounts of data, the software can just make copies of the relatively small data structures and store them in a file. So, that leaves only the disk snapshotting to explain.
First off, what the VM sees as a hard disk is really just a set of files on the host file system. To do a snapshot, the virtual machine software takes the VM's disk at a certain point in time, preserves it, opens a new empty disk file, and does a copy-on-write scheme with every subsequent disk access.
Let's say your disk file is BigVM.disk. You snapshot and now your VM software renames your disk to BigVM-s1.disk, then makes a new empty BigVM.disk. When your VM is running, all read requests go through BigVM.disk. If that file does not have an entry for the part of the disk your VM wants, then the data from BigVM-s1.disk is returned. On a write, the data is written to BigVM.disk instead of BigVM-s1.disk. A future read to that same sector will return the data from BigVM.disk instead of the original snapshot contained in BigVM-s1.disk. BigVM-s1.disk contains your VM's hard disk state as of your snapshot, while BigVM.disk contains all the diffs to your disk since that snapshot.
What happens when you revert to an older snapshot? The VM software throws away the contents of BigVM.disk and starts over, with a new empty BigVM.disk which still points at BigVM-s1.disk.
It is only writing the differences in files changed from the time of the snapshot, not the complete virtual machine disk. Like unix diff and patch, except a more sophisticated version that diffs on a binary level and knows about other details of your virtual machine.
At least in VMware snapshots, what happens is that the snapshot is basically a signal to the VMX to start a new checkpoint for disk writes and machine state. Depending on whether your VM is powered off or on, restoring the snapshot can simply involve just nuking everything that happened past that checkpoint. Otherwise, all of your VM's disk sectors become copy on write, which means when you perform a hot snapshot restoration, it only has to rewrite the sectors that have changed since you took the snapshot. So that's why it's faster.
Working on VMware snapshots and its internal is best explained @ http://www.pcclm.com/2012/02/virtual-machine-snapshots-in-vmware.html
