VMware Cloud Community
maxi-m
Contributor
Contributor
Jump to solution

Would like clarification on reverting back to original image from snapshots

I think I found my answer in another post but would like to confirm,  We are running VMware ESX 4.x in our dev environment and I have been trying use snapshots as an installation program is being tested - so we can revert to a clean server as the scripts are modified and tested.

This is from my entry to an older post which I think answered my question.

Legacy post from 2007:  http://communities.vmware.com/thread/106743?tstart=0

"I realize that this is an older thread and will create a link to it - but just in case anyone follows up on it.

After having issues with "stale" snapshots in the past I stopped using them but for a current project and some encouragement from another group I started using them again.

This thread was very helpful in diagnosing the issue we were having - I used "Delete" trying to revert to the original image and our developer kept saying that there were files from earlier in the day and the event log had entries previous to the current install process.

If this post is correct then "Delete" merges all data into the previous snapshot or V-disk - would appreciate a clear explanation on how it works and what is required to remove all snapshots leaving the base VM in it's origianl state."

0 Kudos
1 Solution

Accepted Solutions
MKguy
Virtuoso
Virtuoso
Jump to solution

"Go to" should be pretty self-explanatory already, although I can understand how some might get confused with the "Delete" option.

First, it's important to understand how Snapshots work. Many new to virtualization assume there will be some kind of copying but that's not how it works. When you create a snapshot, all it does is creating a new delta virtual disk file containing only the changes since creating the snapshot. The original vmdk file will be marked as read-only and all writes will go to your delta file.

As you figured, "Deleting" a snapshot in VMware terms means the delta will be merged into the original vmdk and you won't be able to return to the previous state anymore.

"Go to" or "revert" will move to the selected state where a snapshot was created. This also effectively "deletes" or rather discards the current running delta, so you won't be able to re-revert to that state again unless you create another snapshot. Instead a new empty delta will be created at power-on and filled with subsequent changes. So that also means means your snapshot isn't "deleted" when you revert, as it will just start from 0.

These articles explain everything you should need to know around snapshots:

http://kb.vmware.com/kb/1015180

http://kb.vmware.com/kb/1009402

-- http://alpacapowered.wordpress.com

View solution in original post

0 Kudos
2 Replies
MKguy
Virtuoso
Virtuoso
Jump to solution

"Go to" should be pretty self-explanatory already, although I can understand how some might get confused with the "Delete" option.

First, it's important to understand how Snapshots work. Many new to virtualization assume there will be some kind of copying but that's not how it works. When you create a snapshot, all it does is creating a new delta virtual disk file containing only the changes since creating the snapshot. The original vmdk file will be marked as read-only and all writes will go to your delta file.

As you figured, "Deleting" a snapshot in VMware terms means the delta will be merged into the original vmdk and you won't be able to return to the previous state anymore.

"Go to" or "revert" will move to the selected state where a snapshot was created. This also effectively "deletes" or rather discards the current running delta, so you won't be able to re-revert to that state again unless you create another snapshot. Instead a new empty delta will be created at power-on and filled with subsequent changes. So that also means means your snapshot isn't "deleted" when you revert, as it will just start from 0.

These articles explain everything you should need to know around snapshots:

http://kb.vmware.com/kb/1015180

http://kb.vmware.com/kb/1009402

-- http://alpacapowered.wordpress.com
0 Kudos
maxi-m
Contributor
Contributor
Jump to solution

Thank you very much... that was exactly what I was looking for.  Just some confirmation that these would be correctly managed day forward.

Mike

0 Kudos