VMware Communities
nicknack661
Contributor
Contributor

Duplicated snapshot name

Hi,

I suspended my VM and then I created a snapshot with the same name of an already existing one. Then I tried to delete the old snapshot. But I received a "cannot access file" error and the snapshot disappeared.

At this point, the virtual machine apparently is working but i fear what could happen when I delete the remaining snapshots.

My suspect is that VMWare had overwritten the existing snapshot because I used the same name and had created a mess. I am a bit surprised that VMWare allows that, but that's what happened.

What can I do now?

I am using VMWare workstation 14.1.8.

0 Kudos
9 Replies
scott28tt
VMware Employee
VMware Employee

@nicknack661 

Moderator: Please try and create threads in the area for the product used - moved to Workstation Pro Discussions. The {code} forum area is for API/SDK content.


-------------------------------------------------------------------------------------------------------------------------------------------------------------

Although I am a VMware employee I contribute to VMware Communities voluntarily (ie. not in any official capacity)
VMware Training & Certification blog
0 Kudos
nicknack661
Contributor
Contributor

Sorry.

0 Kudos
wila
Immortal
Immortal

Hi,

How did you create the snapshot?
As you posted in the API/code section, did you create it via code?

If you want to know if it damaged your VM we need to know more..
A filelist to start with.

--
Wil

| Author of Vimalin. The virtual machine Backup app for VMware Fusion, VMware Workstation and Player |
| More info at vimalin.com | Twitter @wilva
0 Kudos
nicknack661
Contributor
Contributor

Hi,

sorry but I posted it in the wrong section.

I created it via UI. That is why I was surprised that VMWare did not complain.

The original snapshot was a cold one, i.e. the VM was turned off. The new snapshot was "hot", i.e. with VM up and running.

Once I received the error message that it was not possibile to delete the first snapshot, it disappeared from the UI. In order to check if there was a naming clash I renamed the duplicated snapshot but the first is missing in any case. Basically in the following snapshot screen there should be one at the beginning called A-BOSD, then the intermediate, then the 3rd still called A-BOSD (which is the one that I then renamed into A-BSOD2).

nicknack661_0-1607953469017.png

Given the issue, I shutted down the VM, copied it onto another disc, restarted it, and in any case it is apparently working. Then I shutted it down again. That been said, how do you want the filelist to be supplied? 

 

 

0 Kudos
nicknack661
Contributor
Contributor

Here is the root folder file list, given that the full filelist (including cache folder) exceeds the maximum characters for a post:

 

Spoiler
ORADATA-000001-s001.vmdk
ORADATA-000001-s002.vmdk
ORADATA-000001-s003.vmdk
ORADATA-000001-s004.vmdk
ORADATA-000001-s005.vmdk
ORADATA-000001-s006.vmdk
ORADATA-000001-s007.vmdk
ORADATA-000001-s008.vmdk
ORADATA-000001-s009.vmdk
ORADATA-000001-s010.vmdk
ORADATA-000001-s011.vmdk
ORADATA-000001-s012.vmdk
ORADATA-000001-s013.vmdk
ORADATA-000001-s014.vmdk
ORADATA-000001-s015.vmdk
ORADATA-000001-s016.vmdk
ORADATA-000001-s017.vmdk
ORADATA-000001-s018.vmdk
ORADATA-000001-s019.vmdk
ORADATA-000001-s020.vmdk
ORADATA-000001-s021.vmdk
ORADATA-000001-s022.vmdk
ORADATA-000001-s023.vmdk
ORADATA-000001-s024.vmdk
ORADATA-000001-s025.vmdk
ORADATA-000001-s026.vmdk
ORADATA-000001-s027.vmdk
ORADATA-000001-s028.vmdk
ORADATA-000001-s029.vmdk
ORADATA-000001-s030.vmdk
ORADATA-000001-s031.vmdk
ORADATA-000001-s032.vmdk
ORADATA-000001.vmdk
ORADATA-000002-s001.vmdk
ORADATA-000002-s002.vmdk
ORADATA-000002-s003.vmdk
ORADATA-000002-s004.vmdk
ORADATA-000002-s005.vmdk
ORADATA-000002-s006.vmdk
ORADATA-000002-s007.vmdk
ORADATA-000002-s008.vmdk
ORADATA-000002-s009.vmdk
ORADATA-000002-s010.vmdk
ORADATA-000002-s011.vmdk
ORADATA-000002-s012.vmdk
ORADATA-000002-s013.vmdk
ORADATA-000002-s014.vmdk
ORADATA-000002-s015.vmdk
ORADATA-000002-s016.vmdk
ORADATA-000002-s017.vmdk
ORADATA-000002-s018.vmdk
ORADATA-000002-s019.vmdk
ORADATA-000002-s020.vmdk
ORADATA-000002-s021.vmdk
ORADATA-000002-s022.vmdk
ORADATA-000002-s023.vmdk
ORADATA-000002-s024.vmdk
ORADATA-000002-s025.vmdk
ORADATA-000002-s026.vmdk
ORADATA-000002-s027.vmdk
ORADATA-000002-s028.vmdk
ORADATA-000002-s029.vmdk
ORADATA-000002-s030.vmdk
ORADATA-000002-s031.vmdk
ORADATA-000002-s032.vmdk
ORADATA-000002.vmdk
ORADATA-000003-s001.vmdk
ORADATA-000003-s002.vmdk
ORADATA-000003-s003.vmdk
ORADATA-000003-s004.vmdk
ORADATA-000003-s005.vmdk
ORADATA-000003-s006.vmdk
ORADATA-000003-s007.vmdk
ORADATA-000003-s008.vmdk
ORADATA-000003-s009.vmdk
ORADATA-000003-s010.vmdk
ORADATA-000003-s011.vmdk
ORADATA-000003-s012.vmdk
ORADATA-000003-s013.vmdk
ORADATA-000003-s014.vmdk
ORADATA-000003-s015.vmdk
ORADATA-000003-s016.vmdk
ORADATA-000003-s017.vmdk
ORADATA-000003-s018.vmdk
ORADATA-000003-s019.vmdk
ORADATA-000003-s020.vmdk
ORADATA-000003-s021.vmdk
ORADATA-000003-s022.vmdk
ORADATA-000003-s023.vmdk
ORADATA-000003-s024.vmdk
ORADATA-000003-s025.vmdk
ORADATA-000003-s026.vmdk
ORADATA-000003-s027.vmdk
ORADATA-000003-s028.vmdk
ORADATA-000003-s029.vmdk
ORADATA-000003-s030.vmdk
ORADATA-000003-s031.vmdk
ORADATA-000003-s032.vmdk
ORADATA-000003.vmdk
ORADATA-s001.vmdk
ORADATA-s002.vmdk
ORADATA-s003.vmdk
ORADATA-s004.vmdk
ORADATA-s005.vmdk
ORADATA-s006.vmdk
ORADATA-s007.vmdk
ORADATA-s008.vmdk
ORADATA-s009.vmdk
ORADATA-s010.vmdk
ORADATA-s011.vmdk
ORADATA-s012.vmdk
ORADATA-s013.vmdk
ORADATA-s014.vmdk
ORADATA-s015.vmdk
ORADATA-s016.vmdk
ORADATA-s017.vmdk
ORADATA-s018.vmdk
ORADATA-s019.vmdk
ORADATA-s020.vmdk
ORADATA-s021.vmdk
ORADATA-s022.vmdk
ORADATA-s023.vmdk
ORADATA-s024.vmdk
ORADATA-s025.vmdk
ORADATA-s026.vmdk
ORADATA-s027.vmdk
ORADATA-s028.vmdk
ORADATA-s029.vmdk
ORADATA-s030.vmdk
ORADATA-s031.vmdk
ORADATA-s032.vmdk
ORADATA.vmdk
vmware-0.log
vmware-1.log
vmware-2.log
vmware.log
Windows Server2012 R2 STD 64bit-0-000001.vmdk
Windows Server2012 R2 STD 64bit-0-000002.vmdk
Windows Server2012 R2 STD 64bit-0-000003.vmdk
Windows Server2012 R2 STD 64bit-0.vmdk
Windows Server2012 R2 STD 64bit-000001.vmdk
Windows Server2012 R2 STD 64bit-000002.vmdk
Windows Server2012 R2 STD 64bit-000003.vmdk
Windows Server2012 R2 STD 64bit-Snapshot212.vmem
Windows Server2012 R2 STD 64bit-Snapshot212.vmsn
Windows Server2012 R2 STD 64bit-Snapshot213.vmem
Windows Server2012 R2 STD 64bit-Snapshot213.vmsn
Windows Server2012 R2 STD 64bit.nvram
Windows Server2012 R2 STD 64bit.vmdk
Windows Server2012 R2 STD 64bit.vmsd
Windows Server2012 R2 STD 64bit.vmx
Windows Server2012 R2 STD 64bit.vmxf

 

 

 

0 Kudos
wila
Immortal
Immortal

Humm.. OK.. in that case there is nothing to worry about.

You can have snapshots with the same name.

See, I just created two "blub" snapshots a few minutes ago.

wila_0-1608133745010.png

They show up just fine with the vmrun API:

$ vmrun -T fusion listsnapshots /Users/wil/Virtual\ Machines.localized/Win10TP/Win10TP.vmx
Total snapshots: 5
Before installing beep
After fresh boop
blub
blub
Yeep

 and the accompanying .vmsd file snippet on my VM looks fine to me too (cut down to only show the relevant part)

snapshot3.uid = "20"
snapshot3.filename = "Win10TP-Snapshot20.vmsn"
snapshot3.parent = "18"
snapshot3.displayName = "blub"
snapshot3.createTimeHigh = "374422"
snapshot3.createTimeLow = "-1229136199"
snapshot3.numDisks = "1"
snapshot3.disk0.fileName = "Win10TP-system-000004.vmdk"
snapshot3.disk0.node = "scsi0:0"
snapshot.mru3.uid = "19"
snapshot4.uid = "21"
snapshot4.filename = "Win10TP-Snapshot21.vmsn"
snapshot4.parent = "20"
snapshot4.displayName = "blub"
snapshot4.createTimeHigh = "374422"
snapshot4.createTimeLow = "-1221038999"
snapshot4.numDisks = "1"
snapshot4.disk0.fileName = "Win10TP-system-000002.vmdk"
snapshot4.disk0.node = "scsi0:0"

As the latter part is the only place that the displayName is set, I am not seeing any issues by doing this.

Note sure why the snapshot would have disappeared, that would be part of the riddle.
If you have a snapshot .vmdk not represented in the .vmsd file then you would indeed have a missing snapshot in the chain.

You can attach filelist (and contents such as a .vmsd file) via a zip file (I hope... you never know with this shitty new forum what you can attach or not)

--
Wil

| Author of Vimalin. The virtual machine Backup app for VMware Fusion, VMware Workstation and Player |
| More info at vimalin.com | Twitter @wilva
0 Kudos
nicknack661
Contributor
Contributor

Hi,

thanks for your answer.

I printed the file list in my last post. I do not know it was not showing up so far... (maybe you're right about the forum).

As you can see, there are only two Snapshot*.vmsn (and vmem) files. The missing snapshot was a cold one so I actually expect another vmsn file (no vmem, right?) but there is nothing.

Your screen is not coming from my version of VMWare so it might be that the management you are pointing out is newer. However, I agree that the snapshot name should not be a problem, given that my file list as actually a number.

So, the issue could have another origin, but still I do not know if I'm missing data. Apparently the VM is working without issues since then.

0 Kudos
wila
Immortal
Immortal

Hi,

Pretty sure that you're not missing data.

If you would miss data then your virtual disk would be corrupted and you would either:
- not being able to boot the VM
- have your guest OS complain about disk corruption issues
I suppose that for an extra test you could run a disk check over your virtual disks. If the guest OS does not report an error then you're safe in regards to lost data.

All snapshots are chained together. If a snapshot goes missing from the user interface then it is always a mismatch in the .vmsd file. The .vmsd file is what is being used to show the snapshot screen and built up the snapshot  tree on there.
The virtual disk itself and its snapshots are in a chain and if the chain is broken you can no longer boot the vm.

It is possible to have snapshots that do not show up in the snapshot tree.
If that's the case then normally you can get rid of those by first deleting all snapshots for your VM. Then create a new snapshot, wait until it is done and immediately delete the snapshot afterwards. Most of the times that gets rid of stray snapshots.

re. different version.
Sorry, I forgot that you used VMware Workstation, my snapshot dialog screenshot is from VMware Fusion.


It does not matter though as both products work exactly the same in this regard.
There is no difference except for the screens.
Even at low level it works the same (and I'm sure about that as it is important for me to know for the backup software that I write on how this works)

 

edit: back to your filelist

You have files that look like:
ORADATA-000001-s001.vmdk  <-- first snapshot, first disk slice
ORADATA-000001-s002.vmdk  <-- first snapshot, second disk slice
ORADATA-000002-s001.vmdk  <-- second snapshot, first disk slice
ORADATA-000002-s002.vmdk  <-- second snapshot, second disk slice
ORADATA-000003-s001.vmdk  <-- third snapshot, first slice
ORADATA-000003-s002.vmdk  <-- third snapshot, second slice
ORADATA-s001.vmdk  <-- base disk, first slice
ORADATA-s002.vmdk  <-- base disk, second slice

So once you remove all snapshots in the snapshot dialog there should be no more ORADATA-00000x-s001.vmdk files.
Also the snapshot dialog should show as many snapshots are there are unique snapshot files.
Note that the numbers do not have to be incremental.

another edit: I forgot to answer one question. No a cold snapshot does not have a .vmsn file, so it is normal for it to not be there.

Hope that helps,
--
Wil

| Author of Vimalin. The virtual machine Backup app for VMware Fusion, VMware Workstation and Player |
| More info at vimalin.com | Twitter @wilva
nicknack661
Contributor
Contributor

Thank you, I think then it's fine.

I should have captured the error message when it presented but I did not quite expect it. I will not investigate any more since till now there are no issues.

0 Kudos