note We are not using vcb or another backup using the ESX's snapshot...

any solution?
I'm having a VM with a big delta file, but snapshot manager is not showing any. I think a backup script did this (crashed)

Is there a way to force the files to be committed?
If I try to create a new snapshot I get a "invalid snapshot configuration..."

Hi,

I've got this kind of problem, too... I'm having 2 delta files and no snapshot is display... Neither within the VC nor with "vmware-cmd /vmfs/volumes/.../ hassnapshot"...

I'd like to commit the existing delta-files but don't know how...

Any suggestions?

with kinds regards,
Sascha

Well I've just had this battle today.
I didn't know how snapshots work, so no idea my Delta-s were silently growing, and growing and growing.
I wanted to export a VM to clone it at another site, and the VMimporter failed.
I looked at the disk and OMFG its 18 GB (machine is 5 GB).
To get this machine working I had taken 6 snapshots as we tried different things, rolled back, tried something else etc (snapshot feature is great).
Once working, I left it to work.

So today I click the "delete all" button and it races to 95% complete and then "hangs". Watching "top" in the console shows no activity. However, the timestamps on the delta's keep changing. So I hope.

Then it goes NUTS. Consuming several hundred MB of disk every few seconds. I frantically delete **** (ISO's mostly) and blow away trashy VMs in the hope of enabling enough disk space.

I fail.

Disk full error message. VM now consuming 25 GB of disk with monster delta files, but VIC says "no snapshots". %$@#$
I do the unregister/register thing, but no joy.
I create a new snapshot, and then do the "delete all" from the command line.
Hmmm, taking a long time for a snapshot that should contain zero changes (machine was down all this time).

Again, the disk munching resumes. I think about two other snapshots that exist for all the other machines, and decide I hate snapshots and delete them from the command line.

Now it could be a coincidence, but when running one of these other commands in another putty session, my main delete fails spetactularly with:

VMControl error -999: Unknown error: SoapError: ServerFaultCode(1514) : (The request refers to an object that no longer exists or has never existed.)

I swear, but my foul language is not required. The deltas are gone. Disk space is back. I open VIC, and hit boot, and pray. It boots. Evenvwr shows it is not some weird rolled back thing from May, but was running today.

So, there you go. Just verbose confirmation of the messages above.
Shutdown
Unregister.
Register.
Take a snapshot
Ensure you have lots of disk space, and LOTS of time (takes hours).
Delete all snapshots.
Pray

Hi, just a quick note based on my experience from today (whilst it is still fresh in my mind). As per suggestions above we did the following.

We actually connected through VI to the VC box. (I seemed to have skipped that part of Mittel's suggestion?!?!)

1. Shutdown the VM
2. Take a new snapshot in Snapshot manager
3. Delete ALL snapshots in Snapshot manager
4. Restart server

It's worth mentioning that on several occasions between actions 3 and 4, I thought it had failed. Including the 'Operation timed out' error. However, looking on the ESX server we could see the delta files were still being modified. We had to keep an eye on space and actually delete an old VM on the go, but eventually, about an hour later, it completed. All delta files had gone and we were left with one shiny vmdk.

Server started happily with events in the Windows system log from the last time the box was up.

If you connect to the host that the particular VM resides on, you can see the progress...even though in VC it says that the "Operation Time Out".