Using the api and ESXi, I often create vm's using the same disk. This works fine as my application always maintains a snapshot, so the base disk is protected.
Deleting a snapshot fails silently when the base disk can't be locked (i.e. another vm is using it.) Actually the delete succeeds....the snapshot is removed; however, the contents of the delta disk are not rolled into the base disk. This has always been the case with ESXi 3.5, 4.0, and 4.1, and I'm not too bothered by it since my use case probably isn't supported.
I bring that up because in 4.1 RevertToSnapshot now fails explicitly. It now tries to lock the base disk when reverting to a snapshot, and fails if other running vm's are using the same base disk (even with their own snapshots). It returns the vm to a poweredOff state, as it should in this case, and then errors with a general system "failed to lock the file". The revert has always worked for me until 4.1.
I'd really love it if the situation was reversed: a snapshot delete should explicitly error if it can't commit changes back to the parent disk, and a revert should not error if it can't lock the parent disk because the parent disk shouldn't be changing. But I'll settle for consistency. 
Thanks for any insight. And sorry if this is in the wrong forum.
P.S. I think this is an old semantic discussion, but I think of "delete snapshot" as "commit snapshot" because the delta data gets rolled into the parent disk. "Delete" has the connotation of "Discard". To actually discard a snapshot, you have to Revert to it to empty the delta disk, and then Delete it, which rolls an empty delta disk into the base disk.