What is a Snapshot

We have heard this term time and again during our journey with working on VMware and many of us are aware of what it is. Still I am including the formal definition of snapshot as below:

Disk Snapshot in VMware refers to a copy of the virtual machine disk file at a certain point in time. It preserves the disk file system and system memory of your virtual machine by enabling you to revert to the snapshot in case something goes wrong.

Snapshots are very helpful in the cases when you are planning to upgrade or patch your mission critical applications and servers.

When a snapshot is taken on a VM then a new disk file by the name *–delta.vmdk is created in the same folder where VM disks are residing (Unless and until you are not using WorkingDir parameter)

All the write operations are freeze on the original vmdk disk present in your VM and the new write operations will be performed on the newly created delta disk. The original vmdk file becomes read only. When a snapshot is taken on a VM certain new files are created in the VM directory. Let’s have a look on those and understand the purpose of those files.

Files associated with snapshot

*–delta.vmdk file: This is the differential file which created snapshot is taken on a VM. It is also known as the redo-log file. A delta file will be created for each snapshot that you create for a VM. An extra delta helper file will also be created to hold any disk changes when a snapshot is being deleted or reverted. These files are automatically deleted when the snapshot is deleted or reverted in snapshot manager.

*.vmsd file: This file is used to store metadata and information about snapshots. This file is in text format and will contain information such as the snapshot display name, unique identifier (UID), disk file name, etc. The size of this file is 0 byte initially until you create first snapshot of a VM. From that point it will populate the file and continue to update it whenever new snapshots are taken.

*.vmsn file: This is the snapshot state file, which stores the exact running state of a virtual machine at the time you take that snapshot. This file will either be small or large depending on if you select to preserve the VM’s memory as part of the snapshot. If you do choose to preserve the VM’s memory, then this file will be a few megabytes larger than the maximum RAM memory allocated to the VM.

A .vmsn file will be created for each snapshot taken on the VM and are automatically deleted when the snapshot is removed.

If you want to look deeper into how snapshot works actually I would recommend reading this wonderful blog post:

http://www.cubicrace.com/2012/02/how-do-virtual-machine-snapshots-work.html

Understanding Snapshot rate of growth and disk space utilization

Many of times I have seen people asking questions (in different group/communities) related to what will be the size of the snapshot delta disk when snapshot is taken and how delta disk grows. By looking into the discussion I have seen sometimes very misleading information given by the users. So let’s understand how delta disk behaves actually.

The size of a snapshot file can never exceed the size of the original disk file. Any time a disk block is changed it is written in the delta file and is updated as changes are made. If every single disk block is changed in your VM after a snapshot is taken, then your snapshot would be of the same size as your original disk file.

There’s some additional overhead disk space that contains information used to manage the snapshots. The maximum overhead disk space varies; it’s based on the Virtual Machine Files System (VMFS) block size. Please refer to the below table:

The required overhead disk space can cause snapshot creation to fail if a VM’s virtual disk is close the maximum VMDK size for a VMFS volume. To understand this consider the below scenario:

A VM’s virtual disk  size is 512 GB on a VMFS volume with a 2 MB block size.In this case the maximum snapshot size would be 516 GB (512 GB + 4 GB), which would exceed the 512 GB maximum VMDK size for the VMFS volume and cause the snapshot creation to fail.

So as a best practice if you are planning to use snapshots, you should always create VMs with a virtual disk size that’s smaller than the maximum VMDK size by the amount of the maximum overhead (e.g., 512 GB – 4GB = 508 GB).

Note: Reference of the above wonderful example is taken from Eric Siebert post on searchvmware.techtarget.com

Initially the size of Snapshot files is small (16 MB), but will grow as writes are made to the VM’s disk files. Snapshots grow in 16 MB increments to help reduce SCSI reservation conflicts. When requests are made to change a block on the original disk, it is instead changed in the delta file. If the previously changed disk block in a delta file is changed again, it will not increase the size of the delta file because it simply updates the existing block in the delta file.

The rate of growth of a snapshot will be determined by how much disk write activity occurs on your server. Servers that have disk-write intensive applications, such as SQL and Exchange, will see snapshot files grow rapidly. On the other hand, servers with mostly static content and fewer disk writes, such as Web and application servers, will grow at a much slower rate.

When we create multiple snapshots, new delta files are created and the previous delta files become read-only. With multiple snapshots, each delta file can potentially grow as large as the original disk file.