2

I found out that my VM is running with a snapshot which is not visible in the snapshot manager. I found out also that the machine is running on a delta file (probably an old snaphot)

I see there are procedures to consolidate snapshots but what I want to understand now is :

Having a VMDK-flat disk of 50gb =>which is actually the vdisk created at the beginning

Now I have a DELTA file of 38 gb...and this file it is growing on daily basis.

My question is : why the delta file is growing ? is that normal ?

Improve this question

3 Answers 3

Reset to default
1

I'm sure some more VM-savvy people will chime in here, but it sounds as though the delta file is doing what it is supposed to.

As far as I know, snapshots work via copy-on-write, where you start out with the original image (that's your vdisk) and an empty file (that's the delta file). Every time anything is changed at all, that change is made on the delta disk. The original disk isn't touched, that way if you ever need to revert to a snapshot, the delta file is thrown away and everything is read from the original vdisk.

Over time, this leads to the side effect of the delta file growing massively as things are changed, added, and removed. As I understand it, if you add a 10MB file, the delta file grows by 10MB. Remove that file, and it grows by another 10MB, because there is a 10MB difference. I could be wrong, and it might actually shrink by 10MB, but I don't think so. (Please someone correct me).

If you consolidate your changes into your snapshot, you'll be back to the original 50GB disk image by itself.

Of course, I could be horribly wrong and mistaken, in which case I'll be voted down, and you should listen to whoever comes in and knows more.

Improve this answer
1
  • 1
    You are correct VMware uses their sparse disk format for disk snapshot delta files which is a COW mechanism. Snapshots can definitely grow as big as the source volume if left runnning for extended periods of time and they never shrink no matter what changes you make until you delete the snapshot.
    – Helvick
    Feb 12, 2010 at 23:44
1

It's normal for the delta file to grow. What Matt says is correct about how snapshots work. What's not normal is the snapshot not showing up in the snapshot manager. I suspect that you can't take any new snapshots of that VM either. It sounds like an orphaned snapshot.

You need to backup and then shut that VM down, if you can.

This KB might help if the snapshot can be detected. Otherwise the only way I solved this in the past was to manually delete the snapshot files, rewrite the .vmx file and bring the VM up in a crashed state, losing all changes in the snapshot.

If the VM won't shut down you need to find the correct process on the host and kill -9 it from the service console.

Then you need to rename or delete all the [guestname]-######-delta.vmdk, [guestname]-######.vmdk, [guestname]-Snapshot###.vmem.WRITELOCK files. Then edit the vmx file. Look for the line scsi0:0.fileName. It should list one of the snapshot files as the hard disk. Change it to the original vmdk file. When you start the VM it will tell you that it had crashed. You lose the contents of the snapshot but at least you'll have the server back.

It's a harsh solution but there's not a whole lot you can do if ESX says there's no snapshot there and the VM refuses to shut down.

Improve this answer
1
  • Would another solution be to run the vmware converter on it, and turn it into another VM, which you can then use to replace the "broken" one?
    – Matt Simmons
    Feb 13, 2010 at 0:20
1

This sort of thing can get very messy. Phosdex and Matt have pretty much covered the worst case scenarios.

I'd recommend following the instructions in this VMware KB1002310 troubleshooting document, it covers the same approach as the one Phosdex linked to but it provides some more tips on how to establish if the snapshots you are looking at are actually associated with the VM you think they are. Sometimes they aren't, I've seen it happen when people move VM's around in an effort to "tidy" things up using the Datastore Browser.

If that still fails you can take a slightly out of the box approach and use VMware Converter to carry out a P2V migration on the VM. Even though it's a virtual machine if you treat it as a physical target Converter will pull the current state from within the context of the Guest OS and wont care if there are dodgy snapshots in some unmanageable state. It will then copy the current state of the VM to a nice fresh clean target leaving the snapshot mess behind. Once you have the converted copy running (isolated from the production network though) you can safely kill the original any way you like and connect the copy to production. Once you are certain the copy is OK you can delete the old VM entirely.

Improve this answer

You must log in to answer this question.