Source

When using the Delete All option in Snapshot Manager, the snapshot farthest from the base disk is committed to its parent, causing that parent snapshot to grow. When the commit is complete, that snapshot is removed and the process starts over on the newly updated snapshot to its parent. This continues until every snapshot has been committed.

This method can be relatively slow since data farthest from the base disk might be copied several times. More importantly, this method can aggressively use disk space if the snapshots are large, which is especially problematic if a limited amount of space is available on the datastore. The space issue is troublesome in that you might choose to delete snapshots explicitly to free up storage.

This issue is resolved in this release in that the order of snapshot consolidation has been modified to start with the snapshot closest to the base disk instead of farthest. The end result is that copying data repeatedly is avoided.

Just to give an example, 4 snapshots:

Old situation (pre vSphere 4 Update 2)

• Base disk – 15GB
• Snapshot 1 – 1GB –> possibly grows to 13GB
• Snapshot 2 – 1GB –> possibly grows to 12GB
• Snapshot 3 – 1GB –> possibly grows to 11GB
• Snapshot 4 – 10GB

Snapshot 4 is copied in to Snapshot 3, Snapshot 3 in to Snapshot 2, Snapshot 2 in to Snapshot 1 and Snapshot 1 in to your Base disk. After the copy of Snapshot 1 in to the Base disk all Snapshots will be deleted. Please note that the total amount of diskspace consumed before the “Delete All” was 28GB. Right before the final merge the consumed diskspace is 61GB. This is just an example, just imagine what could happen with a 100GB data disk!

New situation

• Base disk – 15GB
• Snapshot 1 – 1GB
• Snapshot 2 – 1GB
• Snapshot 3 – 1GB
• Snapshot 4 – 10GB

Snapshot 1 is copied in to Base disk, Snapshot 2 is copied in to Base disk, Snapshot 3 in to Base disk and Snapshot 4 in to your Base disk. After the copy of Snapshot 4 in to the Base disk all Snapshots will be deleted. Please note that the total amount of diskspace consumed before the “Delete All” was 28GB. Right before the final merge the consumed diskspace is still 28GB. Not only did VMware reduced the chances of running out of disk space, the time to commit the snapshot by using “delete all” has also been decreased using this new mechanism.

If you want to be part of the people who directed a VMware feature into a specific direction I would suggest heading over to the survey linked below and fill it out!

I would appreciate it if you could take a few minutes to respond to this survey. Your response will guide our future product offerings in this area. The survey is about 20 questions and should take you just a few minutes to fill out.

I will post a summary of the results after suitable feedback.

Regards,

Henry Robinson
VMware Product Management
The URL to this survey is: http://www.surveymethods.com/EndUser.aspx?B094F8E2B1F2E0E6B6

virtualmachine001
Disk01 – 10GB stored on VMFS001 with a 1MB Block size
Disk02 – 350GB stored on VMFS002 with a 4MB Block size

VMFS001 contains the working directory of the vm “virtualmachine001″. Snapshots are stored in the working directory. In the case of Disk02 this could mean that the delta file grows beyond the maximum file limit of 256GB of VMFS001 where it will be stored.

Another example of where the block size could limit you is outlined in this KB article: http://kb.vmware.com/kb/1012384.

if the disk has been changed in size the following error will show up during the boot process of the VM:

The parent virtual disk has been modified since the child was created

Read the full article for the solution.

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 – 30GB

When you choose “delete all” the following will happen:

1. A helper snapshot is created which holds all changes
2. Snapshot 2 will grow to 40GB at most
3. Snapshot 1 will grow to 60GB at most
4. Snapshot 1 will be committed to the original VMDK
5. The helper is committed to the original
6. 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:

1. a single snapshot will not grow larger than it’ parent disk
2. the disk files are not deleted until everything is consolidated
3. 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.

Before we begin, it’s important to note that defragmentation isn’t a necessary task – your virtual machine will still work just fine even if you never defrag, and the effects of fragmentation are usually not noticeable. Personally, I’ve never feel the need to defrag. However, if for some reason you do feel the need to defrag, here’s how to do it. Note that snapshots get in the way of proper defragmenting.

1. In the VMware Tools installer, select Modify > Drivers > VSS.
2. Complete the installation process.
3. Restart the virtual machine to make sure VSS components are installed and running.

// A fallback to be able to switch to non-quiesced snapshots
if (typeof(NO_QUIESCE) != "undefined") {
cmd +="-Q 0 ";
}

In other words, setting the option “NO_QUIESCE” with no value in config.js results in the VM not being quiesced, default it will quiesce the VM! I added the following line to the  config.js file to accomplish this:

NO_QUIESCE="";