Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We have a tree of about 15 snapshots of a virtual machine that runs Win2k8, as you may guessed our datastore is soon to run out of space. My objective is to delete all the snapshots, as it seems it was a huge mistake to use snapshots for backup purposes.

Now my question is how do we delete the snapshots so that the least amount of space on datastore is used for the merging process, since there is not much space left. Do we start deleting the tree from bottom up, ie. start with deleting the most recent snapshot and move up, or do we start deleting the oldest snapshots and move downward?

share|improve this question
1  
You should delete ALL THE SNAPSHOTS!!! –  ewwhite Apr 25 '13 at 16:29
add comment

5 Answers

up vote 1 down vote accepted

To minimize space used during consolidation:

  1. Shut down the VM. This way the swap file (size of the configured-reserved RAM) is deleted, and you don't need to worry about the temporary snapshot file that is created when deleting snapshots will eat away at your free space while you are deleting snapshots.

  2. Delete from the OLDEST snapshot first. E.G. the one closest to the base. Once that snapshot has been committed, you will increase your disk space. If you start with the newest snapshot, the one furthest from the base, you roll the deleted snapshot changes into the previous snapshot, and it will get larger as you move toward the base. If you are running ESXi 4.0 update 2 or later, it will do this in order for you. If you are running ESXi prior to 4.0 update 2, it will do the opposite PLUS maintain all of the snapshots until it finishes PLUS maintain the temporary snapshot to record activity while the snapshots are being removed. Thus, if you are running a version prior to 4.0 Update 2, it is CRITICAL that you manually delete the oldest first, and work your way to the newest one at a time.

Personally, when I am in that situation, I use this procedure no matter which version of ESXi I'm working on:

  • Shut down the VM.
  • Delete the snapshots one at a time beginning with the oldest snapshot, the one closest to the base, and progressing toward the latest, the one furthest from the base.
share|improve this answer
    
I'm sorry to be a pest but are you SURE about this and haven't made a typo? it's the line "If you start with the newest snapshot, the one furthest from the base, you roll the deleted snapshot changes into the previous snapshot, and it will get larger as you move toward the base" that confuses me, perhaps you could add some detail or references to this please as it strikes me as odd. Thanks in advance. –  Chopper3 Apr 25 '13 at 17:51
add comment

WHY would you have a 'tree of about 15 snapshot'? I know you can but that doesn't mean it's a smart way of doing things, ever heard of a clone or a backup - they're for keeping longer-term point in time copies of VMs, snapshots are just abused by the untrained as they think they're 'free' - they're not.

Either way it's your mess and there's no real way out of it other than to just live with the time it's going to take to delete them all manually from newest to oldest.

share|improve this answer
    
It wasn't my idea, neither my decision... maintenance of servers isn't even my profession, I only know I have to deal with it now. Your rant is not helpful. Is there a logic behind your suggestion of from newest to oldest or that is just a guess? I would really appreciate explanation before I proceed. –  m0s Oct 19 '12 at 18:55
    
Choppers comments isn't a rant. It's damm common sense! –  t1nt1n Oct 19 '12 at 18:59
2  
@m0s - this site is for trained professionals, not meddlers or those trying their best, it's in the first paragraph of our FAQ. The reason you unpick them chronologically is because that's how they're created, via change block tables. –  Chopper3 Oct 19 '12 at 19:01
2  
massively increases the chances of rollback corruption, slows things down and it doesn't handle rollbacks very well - one of the first things you learn on any vS course if use snaps rarely and briefly. –  Chopper3 Oct 19 '12 at 19:04
1  
I really don't see why you were offended so. –  Chopper3 Oct 19 '12 at 19:08
show 6 more comments

This article on VMWare's site indicates that the best approach is to delete the earliest snapshot first (if below ESX4.0U2) or not worry about it:

For versions prior to VMware ESX 4.0 Update-2, the task of consolidating all snapshots (Remove All Snapshots task) caused unique changes stored only in the second snapshot delta disk to be copied upward through the snapshot chain and into the first snapshot, or its "parent". This effect is recursive for each preceding parent file.

Example: You have a base disk of size 8 GB and 2 levels of snapshots, each of 4 GB each. During a Remove All Snapshot Tasks, the first snapshot delta disk file can grow, worse-case scenario, to 8 GB, as all new blocks from the second snapshot are written. Any common changes stored in both snapshot levels do not require additional space.

From ESX4.0 Update 2 onwards, the snapshot mechanism has changed. VMware ESX now incorporates improved consolidation procedures which lessen the demand of free space. You are able to consolidate virtual machine delta disks even while minimal free space on your datastore is available.

If you're only deleting some of the snapshots or need to do it by hand, I would recommend deleting the earliest snapshot first to minimize disk usage, else you could get the situation arising in the example above.

share|improve this answer
    
He may not have the temp space on the DS to do it in that order though. –  Chopper3 Oct 19 '12 at 19:09
    
From reading the docs on VMware's site, the only temp space you need to delete the snapshot is the temporary snapshot that will store the changes done to the disk when committing the delta file back to the base disk. So that's a good piece of advice - try and quiesce activity as much as possible during the snapshot deletion. –  MikeyB Oct 19 '12 at 19:29
add comment

Another option is to clone the VM to another datastore if you have one available. All snapshots are collapsed during cloning.

If you have run out of space and cannot delete all snapshots, clone the virtual machine to a different datastore (you can select a different destination for each virtual disk in the clone wizard). All of the snapshots are committed to the clone virtual machine.

Delete All snapshot operation results in a Consolidate Helper snapshot when a datastore has insufficient disk space

Also, I suggest this as required reading for whomever is responsible for the operation of these servers. (Often being developers.)

Best practices for virtual machine snapshots in the VMware environment

share|improve this answer
add comment

For those who've wound up in this scenario and have found this forum, I hope you read all the answers because Choppers is wrong - IT_Architect is correct.

You need to remove snapshots starting with the snapshot CLOSEST to the base disk.. that is, the snapshot nearest the top of the list in the snapshot manager window. This will minimize the need for free space during the snapshot removal process.

If you followed Choppers method, you'd need a ton of free space available in order to remove all the snapshots successfully - something you probably don't have if you are looking at a chain of 15 open snapshots!

Think about it... only disk changes since the base disk are stored in the first snapshot file. The second snapshot file contains changes since the first snapshot file. The 3rd snapshot only contains changes since the 2nd snap file. The base disk file will NEVER get larger than it's allocated size. Each snapshot file can grow to be the same size as the base disk. See example below

base disk (100 GB) - snap1 (5 GB) - snap2 (3 GB) - snap3 (15 GB)

All the changed disk block that have been stored in snap1 are contained in the base disk. It's just that these blocks have changed since the snapshot was started so they're stored in the snap1 file.

Conversely, the snap3 file is 15 GB and all it's changes cannot possibly be contained in the smaller 3GB snap2 file. If you delete the snap3 snapshot first, it's changes will be merged into the snap2 file. The smallest that snap2 could possibly be is 12 GB after this process and that's assuming that 3 GB of the changes in the snap3 file are the exact same disk blocks in the snap2 file. This is best case scenario.

To make matters worse, during the removal of the snap3 snapshot, the snap3 file remains on the datastore until the snapshot has successfully been removed. Thus, the best case scenario is that you'll use at least 12GB of MORE DISK space in order to remove the snap3 snapshot... but you'll probably need more than that.

That's why you start deleting snapshots closest to the base disk because the base disk file will never grow larger (unless it was thin-provisioned, but that's a different can of worms).

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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