Fusion

How did you delete those "old snapshots"?

Can you post:

• the vmware*.log files found in the VM's bundle
• the data collection file generated by the following script https://community.broadcom.com/vmware-cloud-foundation/viewdocument/get-vmdkmetadatash-script-to-col?CommunityKey=0c3a2021-5113-4ad1-af9e-018f5da40bc0&tab=librarydocuments

We might be able to get our "resident virtual disk corruption expert" to take a look at what's going on

@a_p_ could you look at the files once uploaded? 

Hi Paul, you are always first to step in to help appreciate it!

I used the delete snapshot option below(clicking on the garbage can after highlighting old snapshots I want to delete). I noticed the one I deleted took a bit longer to delete than others before the dependency error came up. You figure VMWare would do a better job letting us know if a snapshot depended on another before you had an option to delete it. Logs are attached. Any help is appreciated! 

How did you delete those "old snapshots"?

Can you post:

• the vmware*.log files found in the VM's bundle
• the data collection file generated by the following script https://community.broadcom.com/vmware-cloud-foundation/viewdocument/get-vmdkmetadatash-script-to-col?CommunityKey=0c3a2021-5113-4ad1-af9e-018f5da40bc0&tab=librarydocuments

We might be able to get our "resident virtual disk corruption expert" to take a look at what's going on

@a_p_ could you look at the files once uploaded? 

From what I see the CID and parent CID settings of all the files for this VM found in the vmdk descriptor files are not what I'd expect to see.

Can you collect the following information as well:

• The vmware-vmfusion*.log files that are found in ~/Logs/VMware\ Fusion and zip those up. It might give us a clue as to what happened during the deletion.
• A listing of all the files in the VM bundle. Looking specifically to see what .vmsn files are present.
• What you did to "repair VMware Fusion snapshot chain CID mismatch" (and did you have a backup of the VM taken before making those changes)?

From what i'm seeing out of the metadata, there are remnants of snapshots that are captured in the metadata whose parent CIDs are incorrect.

Virtual Disk.vmdk has CID 0059e425

Two snapshots appear to have parentCIDs that link to Virtual Disk.vmdk

• Virtual Disk-000006.vmdk - CID= 28d4ddd2, parentCID=0059e425
• Virtual Disk-000003.vmdk - CID=7e4ad9ad, parentCID=0059e425

Three other snapshots appear to be orphaned:

• Virtual Disk-000001.vmdk - CID=14d6dfa1, parentCID=32fb1b42 (parent does not exist in chain)
• Virtual Disk-000002.vmdk - CID=7e4ad9ad, parentCID=7e4ad9ad (parent points to itself which I believe is an error)
• Virtual Disk-000006.vmdk - CID=70ef8d14, parentCID=32fb1b42 (parent does not exist in chain)

 @a_p_ what do you think and is this salvageable?

Hi Paul, you are always first to step in to help appreciate it!

I used the delete snapshot option below(clicking on the garbage can after highlighting old snapshots I want to delete). I noticed the one I deleted took a bit longer to delete than others before the dependency error came up. You figure VMWare would do a better job letting us know if a snapshot depended on another before you had an option to delete it. Logs are attached. Any help is appreciated! 

How did you delete those "old snapshots"?

Can you post:

• the vmware*.log files found in the VM's bundle
• the data collection file generated by the following script https://community.broadcom.com/vmware-cloud-foundation/viewdocument/get-vmdkmetadatash-script-to-col?CommunityKey=0c3a2021-5113-4ad1-af9e-018f5da40bc0&tab=librarydocuments

We might be able to get our "resident virtual disk corruption expert" to take a look at what's going on

@a_p_ could you look at the files once uploaded? 

Here you go. Both files as requested. I actually didn't make any changes to the CID as they seemed to be pointing to the correct (and available) parent snapshot but maybe I was missing something that is obvious. I made backup copies anyways which you will see in the directory listing but didn't make any changes. Thanks again for looking into this!

From what I see the CID and parent CID settings of all the files for this VM found in the vmdk descriptor files are not what I'd expect to see.

Can you collect the following information as well:

• The vmware-vmfusion*.log files that are found in ~/Logs/VMware\ Fusion and zip those up. It might give us a clue as to what happened during the deletion.
• A listing of all the files in the VM bundle. Looking specifically to see what .vmsn files are present.
• What you did to "repair VMware Fusion snapshot chain CID mismatch" (and did you have a backup of the VM taken before making those changes)?

From what i'm seeing out of the metadata, there are remnants of snapshots that are captured in the metadata whose parent CIDs are incorrect.

Virtual Disk.vmdk has CID 0059e425

Two snapshots appear to have parentCIDs that link to Virtual Disk.vmdk

• Virtual Disk-000006.vmdk - CID= 28d4ddd2, parentCID=0059e425
• Virtual Disk-000003.vmdk - CID=7e4ad9ad, parentCID=0059e425

Three other snapshots appear to be orphaned:

• Virtual Disk-000001.vmdk - CID=14d6dfa1, parentCID=32fb1b42 (parent does not exist in chain)
• Virtual Disk-000002.vmdk - CID=7e4ad9ad, parentCID=7e4ad9ad (parent points to itself which I believe is an error)
• Virtual Disk-000006.vmdk - CID=70ef8d14, parentCID=32fb1b42 (parent does not exist in chain)

 @a_p_ what do you think and is this salvageable?

Hi Paul, you are always first to step in to help appreciate it!

I used the delete snapshot option below(clicking on the garbage can after highlighting old snapshots I want to delete). I noticed the one I deleted took a bit longer to delete than others before the dependency error came up. You figure VMWare would do a better job letting us know if a snapshot depended on another before you had an option to delete it. Logs are attached. Any help is appreciated! 

How did you delete those "old snapshots"?

Can you post:

• the vmware*.log files found in the VM's bundle
• the data collection file generated by the following script https://community.broadcom.com/vmware-cloud-foundation/viewdocument/get-vmdkmetadatash-script-to-col?CommunityKey=0c3a2021-5113-4ad1-af9e-018f5da40bc0&tab=librarydocuments

We might be able to get our "resident virtual disk corruption expert" to take a look at what's going on

@a_p_ could you look at the files once uploaded? 

The log file you posted doesn't seem to be the one(s) I was looking for. The logfiles that are of interest have a .log extension and start with vmware-vmfusion  (e.g. vmware-vmfusion.log, vmware-vmfusion-0.log, vmware-vmfusion-1.log)

Here you go. Both files as requested. I actually didn't make any changes to the CID as they seemed to be pointing to the correct (and available) parent snapshot but maybe I was missing something that is obvious. I made backup copies anyways which you will see in the directory listing but didn't make any changes. Thanks again for looking into this!

From what I see the CID and parent CID settings of all the files for this VM found in the vmdk descriptor files are not what I'd expect to see.

Can you collect the following information as well:

• The vmware-vmfusion*.log files that are found in ~/Logs/VMware\ Fusion and zip those up. It might give us a clue as to what happened during the deletion.
• A listing of all the files in the VM bundle. Looking specifically to see what .vmsn files are present.
• What you did to "repair VMware Fusion snapshot chain CID mismatch" (and did you have a backup of the VM taken before making those changes)?

From what i'm seeing out of the metadata, there are remnants of snapshots that are captured in the metadata whose parent CIDs are incorrect.

Virtual Disk.vmdk has CID 0059e425

Two snapshots appear to have parentCIDs that link to Virtual Disk.vmdk

• Virtual Disk-000006.vmdk - CID= 28d4ddd2, parentCID=0059e425
• Virtual Disk-000003.vmdk - CID=7e4ad9ad, parentCID=0059e425

Three other snapshots appear to be orphaned:

• Virtual Disk-000001.vmdk - CID=14d6dfa1, parentCID=32fb1b42 (parent does not exist in chain)
• Virtual Disk-000002.vmdk - CID=7e4ad9ad, parentCID=7e4ad9ad (parent points to itself which I believe is an error)
• Virtual Disk-000006.vmdk - CID=70ef8d14, parentCID=32fb1b42 (parent does not exist in chain)

 @a_p_ what do you think and is this salvageable?

Hi Paul, you are always first to step in to help appreciate it!

I used the delete snapshot option below(clicking on the garbage can after highlighting old snapshots I want to delete). I noticed the one I deleted took a bit longer to delete than others before the dependency error came up. You figure VMWare would do a better job letting us know if a snapshot depended on another before you had an option to delete it. Logs are attached. Any help is appreciated! 

How did you delete those "old snapshots"?

Can you post:

• the vmware*.log files found in the VM's bundle
• the data collection file generated by the following script https://community.broadcom.com/vmware-cloud-foundation/viewdocument/get-vmdkmetadatash-script-to-col?CommunityKey=0c3a2021-5113-4ad1-af9e-018f5da40bc0&tab=librarydocuments

We might be able to get our "resident virtual disk corruption expert" to take a look at what's going on

@a_p_ could you look at the files once uploaded? 

Also, could you post a copy of the .vmsd file for that VM? Just to cross check a few things. 

The log file you posted doesn't seem to be the one(s) I was looking for. The logfiles that are of interest have a .log extension and start with vmware-vmfusion  (e.g. vmware-vmfusion.log, vmware-vmfusion-0.log, vmware-vmfusion-1.log)

Here you go. Both files as requested. I actually didn't make any changes to the CID as they seemed to be pointing to the correct (and available) parent snapshot but maybe I was missing something that is obvious. I made backup copies anyways which you will see in the directory listing but didn't make any changes. Thanks again for looking into this!

From what I see the CID and parent CID settings of all the files for this VM found in the vmdk descriptor files are not what I'd expect to see.

Can you collect the following information as well:

• The vmware-vmfusion*.log files that are found in ~/Logs/VMware\ Fusion and zip those up. It might give us a clue as to what happened during the deletion.
• A listing of all the files in the VM bundle. Looking specifically to see what .vmsn files are present.
• What you did to "repair VMware Fusion snapshot chain CID mismatch" (and did you have a backup of the VM taken before making those changes)?

From what i'm seeing out of the metadata, there are remnants of snapshots that are captured in the metadata whose parent CIDs are incorrect.

Virtual Disk.vmdk has CID 0059e425

Two snapshots appear to have parentCIDs that link to Virtual Disk.vmdk

• Virtual Disk-000006.vmdk - CID= 28d4ddd2, parentCID=0059e425
• Virtual Disk-000003.vmdk - CID=7e4ad9ad, parentCID=0059e425

Three other snapshots appear to be orphaned:

• Virtual Disk-000001.vmdk - CID=14d6dfa1, parentCID=32fb1b42 (parent does not exist in chain)
• Virtual Disk-000002.vmdk - CID=7e4ad9ad, parentCID=7e4ad9ad (parent points to itself which I believe is an error)
• Virtual Disk-000006.vmdk - CID=70ef8d14, parentCID=32fb1b42 (parent does not exist in chain)

 @a_p_ what do you think and is this salvageable?

Hi Paul, you are always first to step in to help appreciate it!

I used the delete snapshot option below(clicking on the garbage can after highlighting old snapshots I want to delete). I noticed the one I deleted took a bit longer to delete than others before the dependency error came up. You figure VMWare would do a better job letting us know if a snapshot depended on another before you had an option to delete it. Logs are attached. Any help is appreciated! 

How did you delete those "old snapshots"?

Can you post:

• the vmware*.log files found in the VM's bundle
• the data collection file generated by the following script https://community.broadcom.com/vmware-cloud-foundation/viewdocument/get-vmdkmetadatash-script-to-col?CommunityKey=0c3a2021-5113-4ad1-af9e-018f5da40bc0&tab=librarydocuments

We might be able to get our "resident virtual disk corruption expert" to take a look at what's going on

@a_p_ could you look at the files once uploaded? 

Also, could you post a copy of the .vmsd file for that VM? Just to cross check a few things. 

The log file you posted doesn't seem to be the one(s) I was looking for. The logfiles that are of interest have a .log extension and start with vmware-vmfusion  (e.g. vmware-vmfusion.log, vmware-vmfusion-0.log, vmware-vmfusion-1.log)

Here you go. Both files as requested. I actually didn't make any changes to the CID as they seemed to be pointing to the correct (and available) parent snapshot but maybe I was missing something that is obvious. I made backup copies anyways which you will see in the directory listing but didn't make any changes. Thanks again for looking into this!

From what I see the CID and parent CID settings of all the files for this VM found in the vmdk descriptor files are not what I'd expect to see.

Can you collect the following information as well:

• The vmware-vmfusion*.log files that are found in ~/Logs/VMware\ Fusion and zip those up. It might give us a clue as to what happened during the deletion.
• A listing of all the files in the VM bundle. Looking specifically to see what .vmsn files are present.
• What you did to "repair VMware Fusion snapshot chain CID mismatch" (and did you have a backup of the VM taken before making those changes)?

From what i'm seeing out of the metadata, there are remnants of snapshots that are captured in the metadata whose parent CIDs are incorrect.

Virtual Disk.vmdk has CID 0059e425

Two snapshots appear to have parentCIDs that link to Virtual Disk.vmdk

• Virtual Disk-000006.vmdk - CID= 28d4ddd2, parentCID=0059e425
• Virtual Disk-000003.vmdk - CID=7e4ad9ad, parentCID=0059e425

Three other snapshots appear to be orphaned:

• Virtual Disk-000001.vmdk - CID=14d6dfa1, parentCID=32fb1b42 (parent does not exist in chain)
• Virtual Disk-000002.vmdk - CID=7e4ad9ad, parentCID=7e4ad9ad (parent points to itself which I believe is an error)
• Virtual Disk-000006.vmdk - CID=70ef8d14, parentCID=32fb1b42 (parent does not exist in chain)

 @a_p_ what do you think and is this salvageable?

Hi Paul, you are always first to step in to help appreciate it!

I used the delete snapshot option below(clicking on the garbage can after highlighting old snapshots I want to delete). I noticed the one I deleted took a bit longer to delete than others before the dependency error came up. You figure VMWare would do a better job letting us know if a snapshot depended on another before you had an option to delete it. Logs are attached. Any help is appreciated! 

How did you delete those "old snapshots"?

Can you post:

• the vmware*.log files found in the VM's bundle
• the data collection file generated by the following script https://community.broadcom.com/vmware-cloud-foundation/viewdocument/get-vmdkmetadatash-script-to-col?CommunityKey=0c3a2021-5113-4ad1-af9e-018f5da40bc0&tab=librarydocuments

We might be able to get our "resident virtual disk corruption expert" to take a look at what's going on

@a_p_ could you look at the files once uploaded? 

Here is the vmsd file. 

Also, could you post a copy of the .vmsd file for that VM? Just to cross check a few things. 

The log file you posted doesn't seem to be the one(s) I was looking for. The logfiles that are of interest have a .log extension and start with vmware-vmfusion  (e.g. vmware-vmfusion.log, vmware-vmfusion-0.log, vmware-vmfusion-1.log)

Here you go. Both files as requested. I actually didn't make any changes to the CID as they seemed to be pointing to the correct (and available) parent snapshot but maybe I was missing something that is obvious. I made backup copies anyways which you will see in the directory listing but didn't make any changes. Thanks again for looking into this!

From what I see the CID and parent CID settings of all the files for this VM found in the vmdk descriptor files are not what I'd expect to see.

Can you collect the following information as well:

• The vmware-vmfusion*.log files that are found in ~/Logs/VMware\ Fusion and zip those up. It might give us a clue as to what happened during the deletion.
• A listing of all the files in the VM bundle. Looking specifically to see what .vmsn files are present.
• What you did to "repair VMware Fusion snapshot chain CID mismatch" (and did you have a backup of the VM taken before making those changes)?

From what i'm seeing out of the metadata, there are remnants of snapshots that are captured in the metadata whose parent CIDs are incorrect.

Virtual Disk.vmdk has CID 0059e425

Two snapshots appear to have parentCIDs that link to Virtual Disk.vmdk

• Virtual Disk-000006.vmdk - CID= 28d4ddd2, parentCID=0059e425
• Virtual Disk-000003.vmdk - CID=7e4ad9ad, parentCID=0059e425

Three other snapshots appear to be orphaned:

• Virtual Disk-000001.vmdk - CID=14d6dfa1, parentCID=32fb1b42 (parent does not exist in chain)
• Virtual Disk-000002.vmdk - CID=7e4ad9ad, parentCID=7e4ad9ad (parent points to itself which I believe is an error)
• Virtual Disk-000006.vmdk - CID=70ef8d14, parentCID=32fb1b42 (parent does not exist in chain)

 @a_p_ what do you think and is this salvageable?

Hi Paul, you are always first to step in to help appreciate it!

I used the delete snapshot option below(clicking on the garbage can after highlighting old snapshots I want to delete). I noticed the one I deleted took a bit longer to delete than others before the dependency error came up. You figure VMWare would do a better job letting us know if a snapshot depended on another before you had an option to delete it. Logs are attached. Any help is appreciated! 

How did you delete those "old snapshots"?

Can you post:

• the vmware*.log files found in the VM's bundle
• the data collection file generated by the following script https://community.broadcom.com/vmware-cloud-foundation/viewdocument/get-vmdkmetadatash-script-to-col?CommunityKey=0c3a2021-5113-4ad1-af9e-018f5da40bc0&tab=librarydocuments

We might be able to get our "resident virtual disk corruption expert" to take a look at what's going on

@a_p_ could you look at the files once uploaded? 

I'm seeing that the .vmsd (snapshot descriptor file) is out of sync with the files that are present on the disk. It has 4 snapshots defined:

Display name: Snapshot 2

• associated with Windows 11 64-bit Arm-Snapshot19.vmsn
• points to Virtual Disk.vmdk 

Display name: Snapshot

• associated with Windows 11 64-bit Arm-Snapshot20.vmsn
• points to Virtual Disk-000003.vmdk 

Display name: Snapshot 3

• associated with Windows 11 64-bit Arm-Snapshot21.vmsn
• points to Virtual Disk-000002.vmdk - which references itself as both CID and parentCID

Display name: Snapshot 4

• associated with Windows 11 64-bit Arm-Snapshot22.vmsn - which does not exist
• points to Virtual Disk-000005.vmdk - which does not exist

No snapshots in the .vmsn file point to Virtual Disk-000006.vmdk or Virtual Disk-00001.vmdk

It may be possible to fix things up, but that's outside my expertise. One thing I'd try that's not destructive is to pick one of the vmdk descriptor files we think is structured correctly (say the base Virtual Disk.vmdk, but Virtual Disk-000003.vmdk or Virtual Disk-000006.vmdk also look like promising candidates). Then create a new Windows 11 ARM virtual machine using the "create a custom virtual machine" option instead of dragging/dropping a ISO file onto the "Select the installation method" dialog. When asked for the virtual disk for the new VM, specify that you'll use an existing virtual disk. In the file selection dialog that appears next, navigate to one of those .vmdk files (in this dialog, the virtual machine bundle will be treated as a directory/folder, enabling you to easily drill down into the bundle to find the file). Before leaving that dialog, make sure you've set the option to copy the virtual disk to the new VM (that way the original one remains intact).

The copy process should consolidate that particular base vmdk or snapshot into the new VM.

Then see if the new VM can power up.  

Here is the vmsd file. 

Also, could you post a copy of the .vmsd file for that VM? Just to cross check a few things. 

The log file you posted doesn't seem to be the one(s) I was looking for. The logfiles that are of interest have a .log extension and start with vmware-vmfusion  (e.g. vmware-vmfusion.log, vmware-vmfusion-0.log, vmware-vmfusion-1.log)

Here you go. Both files as requested. I actually didn't make any changes to the CID as they seemed to be pointing to the correct (and available) parent snapshot but maybe I was missing something that is obvious. I made backup copies anyways which you will see in the directory listing but didn't make any changes. Thanks again for looking into this!

From what I see the CID and parent CID settings of all the files for this VM found in the vmdk descriptor files are not what I'd expect to see.

Can you collect the following information as well:

• The vmware-vmfusion*.log files that are found in ~/Logs/VMware\ Fusion and zip those up. It might give us a clue as to what happened during the deletion.
• A listing of all the files in the VM bundle. Looking specifically to see what .vmsn files are present.
• What you did to "repair VMware Fusion snapshot chain CID mismatch" (and did you have a backup of the VM taken before making those changes)?

From what i'm seeing out of the metadata, there are remnants of snapshots that are captured in the metadata whose parent CIDs are incorrect.

Virtual Disk.vmdk has CID 0059e425

Two snapshots appear to have parentCIDs that link to Virtual Disk.vmdk

• Virtual Disk-000006.vmdk - CID= 28d4ddd2, parentCID=0059e425
• Virtual Disk-000003.vmdk - CID=7e4ad9ad, parentCID=0059e425

Three other snapshots appear to be orphaned:

• Virtual Disk-000001.vmdk - CID=14d6dfa1, parentCID=32fb1b42 (parent does not exist in chain)
• Virtual Disk-000002.vmdk - CID=7e4ad9ad, parentCID=7e4ad9ad (parent points to itself which I believe is an error)
• Virtual Disk-000006.vmdk - CID=70ef8d14, parentCID=32fb1b42 (parent does not exist in chain)

 @a_p_ what do you think and is this salvageable?

Hi Paul, you are always first to step in to help appreciate it!

I used the delete snapshot option below(clicking on the garbage can after highlighting old snapshots I want to delete). I noticed the one I deleted took a bit longer to delete than others before the dependency error came up. You figure VMWare would do a better job letting us know if a snapshot depended on another before you had an option to delete it. Logs are attached. Any help is appreciated! 

How did you delete those "old snapshots"?

Can you post:

• the vmware*.log files found in the VM's bundle
• the data collection file generated by the following script https://community.broadcom.com/vmware-cloud-foundation/viewdocument/get-vmdkmetadatash-script-to-col?CommunityKey=0c3a2021-5113-4ad1-af9e-018f5da40bc0&tab=librarydocuments

We might be able to get our "resident virtual disk corruption expert" to take a look at what's going on

@a_p_ could you look at the files once uploaded? 

Sounds like a great idea but unfortunately I don't have sufficient disk on my Macbook pro to make a separate 200 GB copy of the image. Interestingly enough Virtual Disk-00005.vmdk is selectable but Virtual Disk-000006.vmdk is not. I will see if I can make a cloud backup and delete all snapshots and try again. Thank you for your efforts, much appreciated!!!

I'm seeing that the .vmsd (snapshot descriptor file) is out of sync with the files that are present on the disk. It has 4 snapshots defined:

Display name: Snapshot 2

• associated with Windows 11 64-bit Arm-Snapshot19.vmsn
• points to Virtual Disk.vmdk 

Display name: Snapshot

• associated with Windows 11 64-bit Arm-Snapshot20.vmsn
• points to Virtual Disk-000003.vmdk 

Display name: Snapshot 3

• associated with Windows 11 64-bit Arm-Snapshot21.vmsn
• points to Virtual Disk-000002.vmdk - which references itself as both CID and parentCID

Display name: Snapshot 4

• associated with Windows 11 64-bit Arm-Snapshot22.vmsn - which does not exist
• points to Virtual Disk-000005.vmdk - which does not exist

No snapshots in the .vmsn file point to Virtual Disk-000006.vmdk or Virtual Disk-00001.vmdk

It may be possible to fix things up, but that's outside my expertise. One thing I'd try that's not destructive is to pick one of the vmdk descriptor files we think is structured correctly (say the base Virtual Disk.vmdk, but Virtual Disk-000003.vmdk or Virtual Disk-000006.vmdk also look like promising candidates). Then create a new Windows 11 ARM virtual machine using the "create a custom virtual machine" option instead of dragging/dropping a ISO file onto the "Select the installation method" dialog. When asked for the virtual disk for the new VM, specify that you'll use an existing virtual disk. In the file selection dialog that appears next, navigate to one of those .vmdk files (in this dialog, the virtual machine bundle will be treated as a directory/folder, enabling you to easily drill down into the bundle to find the file). Before leaving that dialog, make sure you've set the option to copy the virtual disk to the new VM (that way the original one remains intact).

The copy process should consolidate that particular base vmdk or snapshot into the new VM.

Then see if the new VM can power up.  

Here is the vmsd file. 

Also, could you post a copy of the .vmsd file for that VM? Just to cross check a few things. 

The log file you posted doesn't seem to be the one(s) I was looking for. The logfiles that are of interest have a .log extension and start with vmware-vmfusion  (e.g. vmware-vmfusion.log, vmware-vmfusion-0.log, vmware-vmfusion-1.log)

Here you go. Both files as requested. I actually didn't make any changes to the CID as they seemed to be pointing to the correct (and available) parent snapshot but maybe I was missing something that is obvious. I made backup copies anyways which you will see in the directory listing but didn't make any changes. Thanks again for looking into this!

From what I see the CID and parent CID settings of all the files for this VM found in the vmdk descriptor files are not what I'd expect to see.

Can you collect the following information as well:

• The vmware-vmfusion*.log files that are found in ~/Logs/VMware\ Fusion and zip those up. It might give us a clue as to what happened during the deletion.
• A listing of all the files in the VM bundle. Looking specifically to see what .vmsn files are present.
• What you did to "repair VMware Fusion snapshot chain CID mismatch" (and did you have a backup of the VM taken before making those changes)?

From what i'm seeing out of the metadata, there are remnants of snapshots that are captured in the metadata whose parent CIDs are incorrect.

Virtual Disk.vmdk has CID 0059e425

Two snapshots appear to have parentCIDs that link to Virtual Disk.vmdk

• Virtual Disk-000006.vmdk - CID= 28d4ddd2, parentCID=0059e425
• Virtual Disk-000003.vmdk - CID=7e4ad9ad, parentCID=0059e425

Three other snapshots appear to be orphaned:

• Virtual Disk-000001.vmdk - CID=14d6dfa1, parentCID=32fb1b42 (parent does not exist in chain)
• Virtual Disk-000002.vmdk - CID=7e4ad9ad, parentCID=7e4ad9ad (parent points to itself which I believe is an error)
• Virtual Disk-000006.vmdk - CID=70ef8d14, parentCID=32fb1b42 (parent does not exist in chain)

 @a_p_ what do you think and is this salvageable?

Hi Paul, you are always first to step in to help appreciate it!

I used the delete snapshot option below(clicking on the garbage can after highlighting old snapshots I want to delete). I noticed the one I deleted took a bit longer to delete than others before the dependency error came up. You figure VMWare would do a better job letting us know if a snapshot depended on another before you had an option to delete it. Logs are attached. Any help is appreciated! 

How did you delete those "old snapshots"?

Can you post:

• the vmware*.log files found in the VM's bundle
• the data collection file generated by the following script https://community.broadcom.com/vmware-cloud-foundation/viewdocument/get-vmdkmetadatash-script-to-col?CommunityKey=0c3a2021-5113-4ad1-af9e-018f5da40bc0&tab=librarydocuments

We might be able to get our "resident virtual disk corruption expert" to take a look at what's going on

@a_p_ could you look at the files once uploaded? 

I wonder if you could have run out of disk space when performing the snapshot deletion/consolidation? "That would be bad"...

Sounds like a great idea but unfortunately I don't have sufficient disk on my Macbook pro to make a separate 200 GB copy of the image. Interestingly enough Virtual Disk-00005.vmdk is selectable but Virtual Disk-000006.vmdk is not. I will see if I can make a cloud backup and delete all snapshots and try again. Thank you for your efforts, much appreciated!!!

I'm seeing that the .vmsd (snapshot descriptor file) is out of sync with the files that are present on the disk. It has 4 snapshots defined:

Display name: Snapshot 2

• associated with Windows 11 64-bit Arm-Snapshot19.vmsn
• points to Virtual Disk.vmdk 

Display name: Snapshot

• associated with Windows 11 64-bit Arm-Snapshot20.vmsn
• points to Virtual Disk-000003.vmdk 

Display name: Snapshot 3

• associated with Windows 11 64-bit Arm-Snapshot21.vmsn
• points to Virtual Disk-000002.vmdk - which references itself as both CID and parentCID

Display name: Snapshot 4

• associated with Windows 11 64-bit Arm-Snapshot22.vmsn - which does not exist
• points to Virtual Disk-000005.vmdk - which does not exist

No snapshots in the .vmsn file point to Virtual Disk-000006.vmdk or Virtual Disk-00001.vmdk

It may be possible to fix things up, but that's outside my expertise. One thing I'd try that's not destructive is to pick one of the vmdk descriptor files we think is structured correctly (say the base Virtual Disk.vmdk, but Virtual Disk-000003.vmdk or Virtual Disk-000006.vmdk also look like promising candidates). Then create a new Windows 11 ARM virtual machine using the "create a custom virtual machine" option instead of dragging/dropping a ISO file onto the "Select the installation method" dialog. When asked for the virtual disk for the new VM, specify that you'll use an existing virtual disk. In the file selection dialog that appears next, navigate to one of those .vmdk files (in this dialog, the virtual machine bundle will be treated as a directory/folder, enabling you to easily drill down into the bundle to find the file). Before leaving that dialog, make sure you've set the option to copy the virtual disk to the new VM (that way the original one remains intact).

The copy process should consolidate that particular base vmdk or snapshot into the new VM.

Then see if the new VM can power up.  

Here is the vmsd file. 

Also, could you post a copy of the .vmsd file for that VM? Just to cross check a few things. 

The log file you posted doesn't seem to be the one(s) I was looking for. The logfiles that are of interest have a .log extension and start with vmware-vmfusion  (e.g. vmware-vmfusion.log, vmware-vmfusion-0.log, vmware-vmfusion-1.log)

Here you go. Both files as requested. I actually didn't make any changes to the CID as they seemed to be pointing to the correct (and available) parent snapshot but maybe I was missing something that is obvious. I made backup copies anyways which you will see in the directory listing but didn't make any changes. Thanks again for looking into this!

From what I see the CID and parent CID settings of all the files for this VM found in the vmdk descriptor files are not what I'd expect to see.

Can you collect the following information as well:

• The vmware-vmfusion*.log files that are found in ~/Logs/VMware\ Fusion and zip those up. It might give us a clue as to what happened during the deletion.
• A listing of all the files in the VM bundle. Looking specifically to see what .vmsn files are present.
• What you did to "repair VMware Fusion snapshot chain CID mismatch" (and did you have a backup of the VM taken before making those changes)?

From what i'm seeing out of the metadata, there are remnants of snapshots that are captured in the metadata whose parent CIDs are incorrect.

Virtual Disk.vmdk has CID 0059e425

Two snapshots appear to have parentCIDs that link to Virtual Disk.vmdk

• Virtual Disk-000006.vmdk - CID= 28d4ddd2, parentCID=0059e425
• Virtual Disk-000003.vmdk - CID=7e4ad9ad, parentCID=0059e425

Three other snapshots appear to be orphaned:

• Virtual Disk-000001.vmdk - CID=14d6dfa1, parentCID=32fb1b42 (parent does not exist in chain)
• Virtual Disk-000002.vmdk - CID=7e4ad9ad, parentCID=7e4ad9ad (parent points to itself which I believe is an error)
• Virtual Disk-000006.vmdk - CID=70ef8d14, parentCID=32fb1b42 (parent does not exist in chain)

 @a_p_ what do you think and is this salvageable?

Hi Paul, you are always first to step in to help appreciate it!

I used the delete snapshot option below(clicking on the garbage can after highlighting old snapshots I want to delete). I noticed the one I deleted took a bit longer to delete than others before the dependency error came up. You figure VMWare would do a better job letting us know if a snapshot depended on another before you had an option to delete it. Logs are attached. Any help is appreciated! 

How did you delete those "old snapshots"?

Can you post:

• the vmware*.log files found in the VM's bundle
• the data collection file generated by the following script https://community.broadcom.com/vmware-cloud-foundation/viewdocument/get-vmdkmetadatash-script-to-col?CommunityKey=0c3a2021-5113-4ad1-af9e-018f5da40bc0&tab=librarydocuments

We might be able to get our "resident virtual disk corruption expert" to take a look at what's going on

@a_p_ could you look at the files once uploaded? 

I don't think so as I have around 80 GB in free space so should be good there. Lesson to be learned is be careful when deleting snapshots. No warning from VMWare Fusion if there are dependencies on older snapshots which seems to be the case here. They should not allow you to proceed with a snapshot delete if there are dependencies. Good idea for a request for product enhancement.

I wonder if you could have run out of disk space when performing the snapshot deletion/consolidation? "That would be bad"...

Sounds like a great idea but unfortunately I don't have sufficient disk on my Macbook pro to make a separate 200 GB copy of the image. Interestingly enough Virtual Disk-00005.vmdk is selectable but Virtual Disk-000006.vmdk is not. I will see if I can make a cloud backup and delete all snapshots and try again. Thank you for your efforts, much appreciated!!!

I'm seeing that the .vmsd (snapshot descriptor file) is out of sync with the files that are present on the disk. It has 4 snapshots defined:

Display name: Snapshot 2

• associated with Windows 11 64-bit Arm-Snapshot19.vmsn
• points to Virtual Disk.vmdk 

Display name: Snapshot

• associated with Windows 11 64-bit Arm-Snapshot20.vmsn
• points to Virtual Disk-000003.vmdk 

Display name: Snapshot 3

• associated with Windows 11 64-bit Arm-Snapshot21.vmsn
• points to Virtual Disk-000002.vmdk - which references itself as both CID and parentCID

Display name: Snapshot 4

• associated with Windows 11 64-bit Arm-Snapshot22.vmsn - which does not exist
• points to Virtual Disk-000005.vmdk - which does not exist

No snapshots in the .vmsn file point to Virtual Disk-000006.vmdk or Virtual Disk-00001.vmdk

It may be possible to fix things up, but that's outside my expertise. One thing I'd try that's not destructive is to pick one of the vmdk descriptor files we think is structured correctly (say the base Virtual Disk.vmdk, but Virtual Disk-000003.vmdk or Virtual Disk-000006.vmdk also look like promising candidates). Then create a new Windows 11 ARM virtual machine using the "create a custom virtual machine" option instead of dragging/dropping a ISO file onto the "Select the installation method" dialog. When asked for the virtual disk for the new VM, specify that you'll use an existing virtual disk. In the file selection dialog that appears next, navigate to one of those .vmdk files (in this dialog, the virtual machine bundle will be treated as a directory/folder, enabling you to easily drill down into the bundle to find the file). Before leaving that dialog, make sure you've set the option to copy the virtual disk to the new VM (that way the original one remains intact).

The copy process should consolidate that particular base vmdk or snapshot into the new VM.

Then see if the new VM can power up.  

Here is the vmsd file. 

Also, could you post a copy of the .vmsd file for that VM? Just to cross check a few things. 

The log file you posted doesn't seem to be the one(s) I was looking for. The logfiles that are of interest have a .log extension and start with vmware-vmfusion  (e.g. vmware-vmfusion.log, vmware-vmfusion-0.log, vmware-vmfusion-1.log)

Here you go. Both files as requested. I actually didn't make any changes to the CID as they seemed to be pointing to the correct (and available) parent snapshot but maybe I was missing something that is obvious. I made backup copies anyways which you will see in the directory listing but didn't make any changes. Thanks again for looking into this!

From what I see the CID and parent CID settings of all the files for this VM found in the vmdk descriptor files are not what I'd expect to see.

Can you collect the following information as well:

• The vmware-vmfusion*.log files that are found in ~/Logs/VMware\ Fusion and zip those up. It might give us a clue as to what happened during the deletion.
• A listing of all the files in the VM bundle. Looking specifically to see what .vmsn files are present.
• What you did to "repair VMware Fusion snapshot chain CID mismatch" (and did you have a backup of the VM taken before making those changes)?

From what i'm seeing out of the metadata, there are remnants of snapshots that are captured in the metadata whose parent CIDs are incorrect.

Virtual Disk.vmdk has CID 0059e425

Two snapshots appear to have parentCIDs that link to Virtual Disk.vmdk

• Virtual Disk-000006.vmdk - CID= 28d4ddd2, parentCID=0059e425
• Virtual Disk-000003.vmdk - CID=7e4ad9ad, parentCID=0059e425

Three other snapshots appear to be orphaned:

• Virtual Disk-000001.vmdk - CID=14d6dfa1, parentCID=32fb1b42 (parent does not exist in chain)
• Virtual Disk-000002.vmdk - CID=7e4ad9ad, parentCID=7e4ad9ad (parent points to itself which I believe is an error)
• Virtual Disk-000006.vmdk - CID=70ef8d14, parentCID=32fb1b42 (parent does not exist in chain)

 @a_p_ what do you think and is this salvageable?

Hi Paul, you are always first to step in to help appreciate it!

I used the delete snapshot option below(clicking on the garbage can after highlighting old snapshots I want to delete). I noticed the one I deleted took a bit longer to delete than others before the dependency error came up. You figure VMWare would do a better job letting us know if a snapshot depended on another before you had an option to delete it. Logs are attached. Any help is appreciated! 

How did you delete those "old snapshots"?

Can you post:

• the vmware*.log files found in the VM's bundle
• the data collection file generated by the following script https://community.broadcom.com/vmware-cloud-foundation/viewdocument/get-vmdkmetadatash-script-to-col?CommunityKey=0c3a2021-5113-4ad1-af9e-018f5da40bc0&tab=librarydocuments

We might be able to get our "resident virtual disk corruption expert" to take a look at what's going on

@a_p_ could you look at the files once uploaded? 

I'm wondering as if you may have indeed uncovered a bug.

You said that you selected multiple snapshots and hit the trash can at the top of the Snapshots window. Did I misunderstand that?

I'm wondering if Fusion (or the underlying vmdk tools used to consolidate snapshots) decided to try to work on multiple snapshots at once and got confused. 

I don't think so as I have around 80 GB in free space so should be good there. Lesson to be learned is be careful when deleting snapshots. No warning from VMWare Fusion if there are dependencies on older snapshots which seems to be the case here. They should not allow you to proceed with a snapshot delete if there are dependencies. Good idea for a request for product enhancement.

I wonder if you could have run out of disk space when performing the snapshot deletion/consolidation? "That would be bad"...

Sounds like a great idea but unfortunately I don't have sufficient disk on my Macbook pro to make a separate 200 GB copy of the image. Interestingly enough Virtual Disk-00005.vmdk is selectable but Virtual Disk-000006.vmdk is not. I will see if I can make a cloud backup and delete all snapshots and try again. Thank you for your efforts, much appreciated!!!

I'm seeing that the .vmsd (snapshot descriptor file) is out of sync with the files that are present on the disk. It has 4 snapshots defined:

Display name: Snapshot 2

• associated with Windows 11 64-bit Arm-Snapshot19.vmsn
• points to Virtual Disk.vmdk 

Display name: Snapshot

• associated with Windows 11 64-bit Arm-Snapshot20.vmsn
• points to Virtual Disk-000003.vmdk 

Display name: Snapshot 3

• associated with Windows 11 64-bit Arm-Snapshot21.vmsn
• points to Virtual Disk-000002.vmdk - which references itself as both CID and parentCID

Display name: Snapshot 4

• associated with Windows 11 64-bit Arm-Snapshot22.vmsn - which does not exist
• points to Virtual Disk-000005.vmdk - which does not exist

No snapshots in the .vmsn file point to Virtual Disk-000006.vmdk or Virtual Disk-00001.vmdk

It may be possible to fix things up, but that's outside my expertise. One thing I'd try that's not destructive is to pick one of the vmdk descriptor files we think is structured correctly (say the base Virtual Disk.vmdk, but Virtual Disk-000003.vmdk or Virtual Disk-000006.vmdk also look like promising candidates). Then create a new Windows 11 ARM virtual machine using the "create a custom virtual machine" option instead of dragging/dropping a ISO file onto the "Select the installation method" dialog. When asked for the virtual disk for the new VM, specify that you'll use an existing virtual disk. In the file selection dialog that appears next, navigate to one of those .vmdk files (in this dialog, the virtual machine bundle will be treated as a directory/folder, enabling you to easily drill down into the bundle to find the file). Before leaving that dialog, make sure you've set the option to copy the virtual disk to the new VM (that way the original one remains intact).

The copy process should consolidate that particular base vmdk or snapshot into the new VM.

Then see if the new VM can power up.  

Here is the vmsd file. 

Also, could you post a copy of the .vmsd file for that VM? Just to cross check a few things. 

The log file you posted doesn't seem to be the one(s) I was looking for. The logfiles that are of interest have a .log extension and start with vmware-vmfusion  (e.g. vmware-vmfusion.log, vmware-vmfusion-0.log, vmware-vmfusion-1.log)

Here you go. Both files as requested. I actually didn't make any changes to the CID as they seemed to be pointing to the correct (and available) parent snapshot but maybe I was missing something that is obvious. I made backup copies anyways which you will see in the directory listing but didn't make any changes. Thanks again for looking into this!

From what I see the CID and parent CID settings of all the files for this VM found in the vmdk descriptor files are not what I'd expect to see.

Can you collect the following information as well:

• The vmware-vmfusion*.log files that are found in ~/Logs/VMware\ Fusion and zip those up. It might give us a clue as to what happened during the deletion.
• A listing of all the files in the VM bundle. Looking specifically to see what .vmsn files are present.
• What you did to "repair VMware Fusion snapshot chain CID mismatch" (and did you have a backup of the VM taken before making those changes)?

From what i'm seeing out of the metadata, there are remnants of snapshots that are captured in the metadata whose parent CIDs are incorrect.

Virtual Disk.vmdk has CID 0059e425

Two snapshots appear to have parentCIDs that link to Virtual Disk.vmdk

• Virtual Disk-000006.vmdk - CID= 28d4ddd2, parentCID=0059e425
• Virtual Disk-000003.vmdk - CID=7e4ad9ad, parentCID=0059e425

Three other snapshots appear to be orphaned:

• Virtual Disk-000001.vmdk - CID=14d6dfa1, parentCID=32fb1b42 (parent does not exist in chain)
• Virtual Disk-000002.vmdk - CID=7e4ad9ad, parentCID=7e4ad9ad (parent points to itself which I believe is an error)
• Virtual Disk-000006.vmdk - CID=70ef8d14, parentCID=32fb1b42 (parent does not exist in chain)

 @a_p_ what do you think and is this salvageable?

Hi Paul, you are always first to step in to help appreciate it!

I used the delete snapshot option below(clicking on the garbage can after highlighting old snapshots I want to delete). I noticed the one I deleted took a bit longer to delete than others before the dependency error came up. You figure VMWare would do a better job letting us know if a snapshot depended on another before you had an option to delete it. Logs are attached. Any help is appreciated! 

How did you delete those "old snapshots"?

Can you post:

• the vmware*.log files found in the VM's bundle
• the data collection file generated by the following script https://community.broadcom.com/vmware-cloud-foundation/viewdocument/get-vmdkmetadatash-script-to-col?CommunityKey=0c3a2021-5113-4ad1-af9e-018f5da40bc0&tab=librarydocuments

We might be able to get our "resident virtual disk corruption expert" to take a look at what's going on

@a_p_ could you look at the files once uploaded?