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:

  1. Discard snapshot: very fast action. Virtual machine manager simply deletes snapshot image file and returns control onto the original disk image or some of the previous snapshots
  2. Merge snapshot: virtual machine manager merges changed blocks (i.e. snapshot image) with original image. This action will take time depending on how much blocks from original image have changed. Again, worst case scenario is that whole original image will be overwritten in case that all blocks from original image have been written after creation of a snapshot.

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.

|improve this answer|||||
  • 1
    discard snapshot, like any image deletion process, can actually be quite slow, if you have the wipe-after-delete turned on. It's a security feature to wipe the space used by an image or snapshot clean before it is freed to be used by other VMs, otherwise, using low level block reading, it can be possible to read the data the previous VM used. And any virtualization solution that doesn't have this feature has a huge security flaw in it – dyasny Feb 16 '11 at 16:26
  • I've tried to explain the scenario of creating multiple snapshots and how the changes with each snapshot are retained. See this short explanation on the working of VMware snapshots: cubicrace.com/2012/02/… – Piyush Chordia Apr 18 '16 at 4:57

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.

|improve this answer|||||

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.

|improve this answer|||||

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.

|improve this answer|||||

Working on VMware snapshots and its internal is best explained @ http://www.pcclm.com/2012/02/virtual-machine-snapshots-in-vmware.html

|improve this answer|||||
  • 3
    Welcome to ServerFault! Although linking to external reference material is encouraged, we also expect each answer to be complete even if your links become broken in the future. You may wish to edit this answer and add additional details. – Skyhawk Dec 14 '12 at 6:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.