VM Snapshot

[Handian Sudinato]

Hello,

what file actually is vm snapshot? ON the VM i can see i have one snapshot with 200GB, then if i browse the file vm snapshot type is only 35.43 KB, is virtual disk JKTAPPSDEV.vmdk actualy the snapshot file?

 

[Sachchidanand Upadhyay]

Please see the below KB

https://kb.vmware.com/s/article/1015180

Regards,

Sachchidanand

[Nick Merlevede]

Snapshot file that represents the difference between the current state of the virtual disk and the state that existed at the time the previous snapshot was taken.

The filename uses the following syntax, S1vm-000001.vmdk where S1vm is the name of the virtual machine and the six-digit number, 000001, is based on the files that already exist in the directory. The number does not consider the number of disks that are attached to the virtual machine.

https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.hostclient.doc/GUID-38F4D574-ADE7-4B80-AEAB-7EC502A379F4.html

So for your vm it shout be the file: JKTAPPSDEV-0000001.vmdk

[Maksym Roshchyna]

Check also that one 
https://kb.vmware.com/s/article/1025279 

[Mark Edwards]

 - Yes you are correct.

When you take a snapshot (lets call it Snapshot#1), the base disk JKTAPPSDEV.vmdk is made read only, and a new "delta" vmdk is created that contains the changed blocks (ie running changes) from that point forwards. That file is JKTAPPSDEV-000001.vmdk.

 

In the GUI, Snapshot #1 points to → JKTAPPSDEV.vmdk, and "you are here" points to → JKTAPPSDEV-000001.vmdk

 

If you revert to Snapshot #1, JKTAPPSDEV-000001.vmdk (and all the changes it contains) is deleted, and JKTAPPSDEV.vmdk (your base disk) becomes read/write again. CORRECTION (as pointed out in next post) - Following a revert your base disk remains read only (because of course - it is still a snapshot). What happens is the previous delta vmdk is deleted (and changes up to that point are lost) and a new delta vmdk is created in its place. Thanks  for picking up my mistake ! 

Alternatively if you delete Snapshot #1, all the blocks contained in the delta disk (JKTAPPSDEV-000001.vmdk) are committed (ie merged) into the base disk, and the delta disk is deleted.

 

HTH

 

[a_p_]

 

Just a quick note:

You said: "If you revert to Snapshot #1, JKTAPPSDEV-000001.vmdk (and all the changes it contains) is deleted, and JKTAPPSDEV.vmdk (your base disk) becomes read/write again."

Reverting to a snaphot does not change that snapshot to which you revert, i.e. does not make it R/W. Reverting to a snapshot will disacard/delete the current "You are here" delta/sesparse file, and create a new child delta/sesparse file for the state that you reverted to.

André

[Mark Edwards]

Thanks  - Doh, you're quite right of course, thanks for the correction . Edited my post to correct that bit 

[acpzehetal]

The file with .vmsn is only the decriptor file which is used by the Snapshot management and the GUI, that there is a snapshot according to the VM.

The original file is the -000001.vmdk with the snapshot geometry and the sectors written to it. According to your screenshot it seems allright.

[Mark Edwards]

 

Except that vmsn file has a much older timestamp, and a name that doesn't align with the current snapshot, and therefore does not relate to that snapshot, as far as i can tell.

 

Something doesn't look right there to me. It seems the current snapshot is missing a descriptor file, and the descriptor file that IS there, is for a snapshot that has since been deleted.

[acpzehetal]

I didn´t see the timestamps, but you might be allright with your conclusion. If the files aren´t corresponding with each other, you have to deal with "orphaned" snapshots and consolidate them from the shell.

Even if this issue is a very old one the repair of missing references and orphaned snapshot hasn´t been changing. Here is some information what you can do with it:

https://angrysysops.com/2021/10/08/how-to-remove-stale-orphaned-snapshots-in-the-datastore-on-which-the-virtual-machine-resides/

But you have be careful about diagnosing the status of the VM. There might be a running reference inside the vmdk-geometry.