VMware Cloud Community
Jeff11173
Contributor
Contributor

Snapshot deletion question

I have seen a few times where snapshots get so large that they take up all available free space on the datastore, thereby halting the VM and it will not start back up. We tried to delete the snap but it would take several hours and for production that is a pricey resolution. On a "not so important" VM we had the same issue and I just went into the datastore browser and searched for snapshots, then deleted it. The machine started up and is running without issues.

What are the risks/problems with doing that?

Thanks everyone!

Reply
0 Kudos
13 Replies
Chris_Howard
Hot Shot
Hot Shot

Hi - deleting the snapshot files directly is probably not a good idea. - these contain the changes to the disk made since that snapshot was taken.

By deleting them, you would revert your disk back its state when the snapshot was taken.

A more detailed explanation of how snapshots work can be found here and here.

If you found this helpful please consider the use of the Helpful /Correct buttons to award points. Thanks !!

If you found this helpful please consider the use of the Helpful /Correct buttons to award points. Thanks !!
petedr
Virtuoso
Virtuoso

I wouldn't suggest doing that as well, besides losing all the changes in the snapshots, I don't know what other files may be out of synch thinking a snapshot is there when it actually isn't.

www.thevirtualheadline.com www.liquidwarelabs.com
Jeff11173
Contributor
Contributor

Thanks for the input guys. There is some confusion from different people and different sites as to how snapshots work.

I just tried it on a test box to confirm I wasn't going bonkers.....

Manually deleting a snapshot from the datastore browser does not lose any changes that have been made since the snap, it only loses the ability to revert. It does however show in snapshot manager that there is still a snap available which seems to be needing the extra .vmdk files to be committed before it clears up. The snapshot file is huge in comparison to the extra .vmdk files that house the "original data" by deleting the snapshot file it seems that we are only deleting the changes and therefore if your VM is down due to a lack of datastore freespace, then this is an acceptable way to get back up and running. Then you can comeback later while the VM is running and commit those extra .vmdk files. At that point who cares if it takes 4 hours to get off that 95% Smiley Happy

Does that make sense? Or am I off my rocker?

Reply
0 Kudos
admin
Immortal
Immortal

A snapshot file is basically a transaction log of changes that would be made to the original disk. There are several reasons why not to manually delete the file.

The first is obviously that you are going to lose data. The VM will be reverted back to the point in time that the snap was made.

The second is that all the vmdk files are tied to each other. If you look in the descriptor files you will notice that there are 2 entries, PID and CID. These are the Parent disk ID and Child disk ID. Each time you have a snapshot, the current disk becomes the Parent and the newly created snap becomes the child. If people continously add snapshots you can get quite the train of files.

The third thing is that the vmx file points to the current snap as the disk for the VM. You will see the 00001.vmdk listed as the disk and not the original vmdk. When you try to start the VM it should complain that the disk is missing. It may be intelligent enough to roll back to the root disk, but it's still very bad practice.

Corey

Reply
0 Kudos
Jeff11173
Contributor
Contributor

Drysdale,

Thanks for the input.

Your statement "The first is obviously that you are going to lose data. The VM will be reverted back to the point in time that the snap was made." is simply not true. I talked about that in my prior post.

Reply
0 Kudos
Texiwill
Leadership
Leadership

Hello,

Whether or not you loose data depends entirely where you are within the snapshot manager when you are running. If you are running 'from the snapshot' you are collecting within the snapshot VMDK a transaction long of all disk changes with respect to the parent disk. If you delete that snapshot VMDK then you will loose ALL the changes you have made to that point and revert back to the original VMDK. If you are not running 'from the snapshot' but the main disk then you are perfectly fine. The snapshot is then ignored until you run from it. Snapshots can grow to be enormous (several times the size of the original disk). If you have multiple snapshots, then you can choose to run from any number of them.

Manually deleting snapshot files will result in data loss depending on several possible runtime constraints.

For VMware ESX, snapshots should not be used heavily as they will adversely affect performance if they hang around tooo long and grow to large.

Note that 'Delete' within the Snapshot manager actually refers to a Commit. Hence no data loss. I wish they would change that, but deleting direct from disk and patching the .vmsn, and .vmx files will result in data loss depending on the constraints above.


Best regards,

Edward L. Haletky

VMware Communities User Moderator

====

Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education. CIO Virtualization Blog: http://www.cio.com/blog/index/topic/168354, As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
Reply
0 Kudos
Draconis
Enthusiast
Enthusiast

Hi Texi,

You stated that a snapshot can grow several times the size of the original disk. I was told by my trainer that each snapshot can grow up to the size of the original vmdk file. Collectively, they could possibly grow several times the original size of the original disk. Is that what you meant or can a snapshot actually grow larger than the original vmdk file size?

If you have found my answer helpful or correct, please consider awarding points.
Reply
0 Kudos
Texiwill
Leadership
Leadership

Hello,

Yes it is possible for a snapshot to grow to several times the size of the original VMDK as the snapshot is a more a FIFO than anything else. I had a 20GB VMDK and ended up with a 100GB Snapshot file once. Was a royal pain to commit.


Best regards,

Edward L. Haletky

VMware Communities User Moderator

====

Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education. CIO Virtualization Blog: http://www.cio.com/blog/index/topic/168354, As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
Reply
0 Kudos
Draconis
Enthusiast
Enthusiast

Well that helps alot planning for a VMWare deployment now that I know it can grow larger than the original. Its more dynamic than I initially thought but thats all good. Thanks alot.

If you have found my answer helpful or correct, please consider awarding points.
Reply
0 Kudos
Brianck
Enthusiast
Enthusiast

We have seen it where we could not delete/committe a snap shot using VC but if we ran the post bat file from our proxy server it worked just fine. We use CommVault with the external pre and post scripts on a proxy host.

Reply
0 Kudos
Draconis
Enthusiast
Enthusiast

I guess if I was in the same boat as Jeff and I couldnt put my finger on why I couldnt delete a snapshot, good thing in his case he was able to, that would pretty much eat up my day, not to mention annoy a bunch of managers. Is Brianck's issue an isolated issue or has anyone else experienced this? What were the sizes of your snapshots before resorting to running bat files?

If you have found my answer helpful or correct, please consider awarding points.
Reply
0 Kudos
Brianck
Enthusiast
Enthusiast

We have had one of two that were DB's and the shots grew to gb's quickly and ran the vmfs out of space (we only leave 10gb free on average per vmfs). We have seen this a few times in the past but we never have been able to isolate the cause. Now we use the snap.vbs script that someone here wrote to check on existance of snapshot. Using that vbs script I added a VB wrapper that puts it in a pretty display and also e-mails out alerts to admins after a snap has been active for more than 30 minutes so we can prevent the vmfs from running out of space and bringing down the vm's.

Reply
0 Kudos
Draconis
Enthusiast
Enthusiast

Oh, fancy. Thanks. :smileygrin:

If you have found my answer helpful or correct, please consider awarding points.
Reply
0 Kudos