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.
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.
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.
don't delete them or your VMs will be broken, commit them or revert them
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.
My fault - I should have written "don't delete them MANUALLY"
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.
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?
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.