Yellow Bricks

by Duncan Epping

snapshots

Changes to Snapshot mechanism “Delete All”

· ·

Don’t know if anyone noticed it or not but with the latest set of patches VMware changed the “Delete All” mechanism that is part of the Snapshot feature. I wrote multiple articles about the “Delete All” functionality as it often led to completely filled up VMFS volumes when someone used without knowing the inner workings.

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.

Feedback on VMware Snapshots

· ·

Henry Robinsson, a product manager at VMware, just posted a topic on the VMTN community forums requestion feedback on VMware snapshots. (Thanks William Lam for pointing this out) I am uncertain what this feedback will lead into but usually it is used as guidance for the direction a specific product or feature is heading into.

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

vSphere VM Snapshots and block size

· ·

As some already noticed; when creating a snapshot on a VM with two disks the block size of the VMFS volume which hold the working directory is checked before the snapshot is taken. As reported by VMTN User Pizang this was not the case in ESX 3.x. You can imagine that this can cause issues when the second disk of a VM is larger than the maximum file size dictated by the block size of the VMFS file system which holds the working directory of the VM. What? Yeah I had to read that sentence at least 3 times before I understood what I said… This might make it easier:

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.

Consolidating snapshots

· ·

I was just reading this excellent KB article on consolidating snapshots. It really contains a wealth of information and a procedure on how to remove a snapshot of a disk that has been changed in size for instance.

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.

Snapshots, the revision

· ·

I was reading Jason Boche’s blog on snapshots yesterday and noticed a misunderstanding. I tweeted Jason about this and his blog was updated in a sec. But I thought it might be handy to actually outline the basics again especially because during the VMTN Experts Podcast there was a huge discussion on snapshots. Unfortunately I could not join the call via audio so I decided to respond here. [Read more…] about Snapshots, the revision