Virtual Machine Snapshots with Hyper-V

Snapshots are a new feature of Windows Server 2008 Hyper-V. Snapshots are a point in time version of a virtual machine…..what does that mean you ask? It means that you can be running a virtual machine, take a snapshot and at any point you can select a previous snapshot and revert back to that point in time.  You end up with the virtual machine in the EXACT configuration that it was when you took the snapshot…and I mean exact….memory, virtual hardware, processes, state, etc. So you can have a running virtual machine, take a snapshot, change the virtual hardware configuration, format the disk and install a different OS, it does not matter, when you apply the previous snapshot it looks exactly like it did when you took the snapshot.

Snapshots do not affect the running state of the virtual machine, meaning that taking a snapshot does not change the virtual machine hardware, applications, or the currently running processes. It also means that deleting a snapshot does not change the virtual machine either….it just means that you cannot go OOPS and go back to that point in time to get you out of something you just did.

The snapshot files consist of the following:

  • A copy of the VM configuration .xml file
  • Any save state files
  • A differencing disk(.avhd) that is the new working disk for all writes that is the child of the working disk prior to the snapshot.

If you create snapshots one right after each other and never apply a previous snapshot, the you will have a tree with one branch. if you apply a previous snapshot, then you will get another branch to the snapshot tree starting at the applied snapshot.

Creating Snapshots – How does it work?

When you create a new VM in a directory, let’s say D:\TestVM, two sub directories are created – D:\TestVM\Snapshots and D:\TestVM\Virtual Machines. The \Snapshots directory contains nothing, but the \Virtual Machines directory contains the original XML configuration file saved with a unique GUID as the filename with an .xml extension and a directory to house the save state files (.VSV and .bin) memory files. The directory also uses the same GUID as the directory name. I will refer to this as the VMGUID.

Note: All the filenames and directories are actual GUIDs, I am using friendly names to make it easier to write and understand the concept.

The VMGUID.XML file points to the D:\TESTVM\TESTVM.VHD as the current VHD for all writes. Before you do any snapshots, all changes get written to the D:\TESTVM\TESTVM.VHD file and any save state is saved in the D:\TestVM\Virtual Machines\VMGUID directory.

When you create the first snapshot you have two scenarios: [1] You create it with the virtual machine powered down or [2] you create it while the virtual machine is running.

CASE [1] – VM is powered off

  1. It creates two directories in the D:\TestVM\Snapshots\ folder
  • One with a folder name of VMGUID – this is where all the avhd files will be stored for all snapshots (This only happens for the first snapshot)
  • One with a new GUID for a folder name – this is where the memory save state for this snapshot is stored, I will refer to this as SNAPGUID
  • In this case no files are written to D:\TestVM\Snapshots\SNAPGUID here because the VM is powered down and there is no memory state
  1. It also creates a copy of the VM’s XML configuration file with filename SNAP1GUID.XML
  2. It creates a working .avhd files with another GUID and stores it in the D:\TESTVM\Virtual Machines\VMGUID directory. I will refer to this as WORKING.AVHD
  3. The VM’s original VMGUID.XML file is updated to point to the new WORKING.AVHD as current VHD

CASE [2] – VM is powered on

  1. Everything that happens for CASE [1] happens for case [2] except in this case the memory is saved to disk and stored in the D:\TestVM\Snapshots\SNAPGUID folder as a BIN with the actual memory saved and a VSV with supporting process information.

Both Case [1] and [2] proceed the same from here….

From this point on, all writes are written to the WORKING.AVHD file. If you make a bunch of changes and then decide to use Revert (to go back to the point in time of the first snapshot), this is what happens

  1. The WORKING.avhd file is deleted and a new one is created with a different GUID
  2. The VM’s original VMGUID.XML file is updated to point to the new WORKING.AVHD as current VHD
  3. If there was a save state file to load it would be loaded and the VM would be resumed from save state.
  4. If there was no save state file to load, the machine would remain powered down since you took the snapshot when it as powered down.

So you make a bunch of more changes and then take another snapshot, this is what happens

  1. A copy of the current VMGUID.XML files is made, placed in the SNAPSHOTS folder and given a filename with a new GUID, let’s call it SNAP2GUID.XML
  2. A folder is created in the SNAPSHOTS folder using the SNAP2GUID to house the save state files for this snapshot, The VM is save stated to this folder
  3. The current D:\TESSTVM\Snapshots\VMGUID\WORKING.AVHD file is now the point in time state of the VHD (the GUID does not change)
    • Its parent is the original TESTVM.VHD file
  4. A new WORKING.AVHD file is created with a new GUID
    • Its parent is the old WORKING.AVHD file
  5. The VMGUID.XML file is updated to the new WORKING.AVHD

So for each new snapshot in succession

  1. A copy of the current VMGUID.XML is made and placed in the VMs SNAPSHOTS folder, the filename is a unique GUID
  2. A new directory is created in the SNAPSHOTS folder to hold the save state files, the folder name is the same as the GUID in (a) above
  3. A new avhd file is created with a new unique GUID. This becomes the new working avhd file and the existing one becomes the RO parent.
  4. All new writes are made to the new working avhd file

Hope that provides you with a better understanding on what snapshots are and how they are created under the hood…..I will save deleting snapshots for a future post :-)