VMware Cloud Community
ramonet
Contributor
Contributor
Jump to solution

Freeing space on storage by deleting snapshots

Hi all. I think this is really an easy one, but I'm beginning to use vmware and I'm a bit lost.

I'm running out of space on my storage, in a ESX 3. I've got only 12, 3 Gb free and I'm a bit scared about it.

I've 2 VM's containing snapshots and I guess that deleting them all could free up significant space. How could I know how much would it be? Has it anything to do with the size of the -delta.vmdk files?

Is there any (potential) problem in deleting snapshots when the VM's are up (they're production environment) or should it be better powering them off prior to deleting them?

Thanks in advance.

Reply
0 Kudos
1 Solution

Accepted Solutions
admin
Immortal
Immortal
Jump to solution

In my case the VM carried on working after I manually editted the .vmx file to tidy up the left over snapshot entries for the 3 VMDKs that did commit successufully (was still pointing at snapshots that didn't exist so VM wouldn't power on). However two of the 5 VMDKs still have snapshots associated with them and I was unable to commit these to free up the space, even with the help of VMware support.

I suggest you do a full backup of the VM (from within the guest) before trying the commit, just in case. You might be OK it depends how busy the VM has been over the last two months and how big the delta files have become.

View solution in original post

Reply
0 Kudos
7 Replies
kix1979
Immortal
Immortal
Jump to solution

If the snapshots are big, it may cause the VM to be unresponsive during the commit. If they are large and you can afford the downtime, I would advise committing while the VM is offline.

Thomas H. Bryant III
Reply
0 Kudos
oreeh
Immortal
Immortal
Jump to solution

don't delete them or your VMs will be broken, commit them or revert them

Reply
0 Kudos
Jae_Ellers
Virtuoso
Virtuoso
Jump to solution

From the snapshot manager you can "delete" the snapshot, which means commit.

Don't delete the -delta* from the filesystem or you're toast.

Yes, the delta file is the snapshot. So this space will be recovered. If this is many gigs consider the previous posters idea of shutting down and then removing the snapshot. It will speed up the process anyway.

Snapshots on ESX should really just be used for brief tests or changes. Production vms shouldn't be running any snapshots.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=- http://blog.mr-vm.com http://www.vmprofessional.com -=-=-=-=-=-=-=-=-=-=-=-=-=-=-
oreeh
Immortal
Immortal
Jump to solution

My fault - I should have written "don't delete them MANUALLY"

Reply
0 Kudos
admin
Immortal
Immortal
Jump to solution

Totally agree, snapshots in 3.0.1 are very flakey, if you leave a VM snapshotted for any length of time the chances are that you will experience problems trying to commit it.

I've recently had to image the data from a VM to a new VM with Ghost (on the recommendation of VMware support) because when I tried to commit it's snapshots only 3 of the 5 attached VMDKs actually commited, leaving the other two in a strange limbo state with snapshots that could not be commited. Not much fun with 340GB of data. The VM was powered off when I attempted the commit.

ramonet
Contributor
Contributor
Jump to solution

So, you're telling me that I might have problems even if the vm is powered off. I've had these snapshost for about two months, so the odds are I could be in trouble. What kind of trouble? Leaving the vm in an unstable state or, perhaps, not being able to freeing that space but keeping the vm working?

Reply
0 Kudos
admin
Immortal
Immortal
Jump to solution

In my case the VM carried on working after I manually editted the .vmx file to tidy up the left over snapshot entries for the 3 VMDKs that did commit successufully (was still pointing at snapshots that didn't exist so VM wouldn't power on). However two of the 5 VMDKs still have snapshots associated with them and I was unable to commit these to free up the space, even with the help of VMware support.

I suggest you do a full backup of the VM (from within the guest) before trying the commit, just in case. You might be OK it depends how busy the VM has been over the last two months and how big the delta files have become.

Reply
0 Kudos