VMware Cloud Community
iohr
Contributor
Contributor
Jump to solution

The virtual disk is either corrupted or not a supported format.

We've got a 2008 R2 Datacenter SP1 VM that we cannot snapshot.

A manual snapshot from within the vSphere Client shows the following in the Tasks and Events:

The virtual disk is either corrupted or not a supported format.

Our NetBackup software does automated snaphots for VM backups and generates these three errors in the Tasks and Events:

A snaphot operation cannot be performed

Operation timed out

A general system error occurred: Protocol error from VMX.

The VM has two Virtual Disks:

[vmds-standard:default (1)] outhostname/ourhostname-000001.vmdk

[vmds-standard:default (1)] outhostname/outhostname_1-000001.vmdk

The virtual disk files do not appear to have the usual filenames. Instead they look like snapshot files or something similar.

I'm not sure what's going on. Can anybody help?

Tags (2)
0 Kudos
1 Solution

Accepted Solutions
a_p_
Leadership
Leadership
Jump to solution

The file names are correct since there's an active snapshot on the VM. I found a few entries in the log file which we/you could check:

Mar 23 08:01:25.543: vmx| DICT        scsi0:2.deviceType = scsi-hardDisk
Mar 23 08:01:25.543: vmx| DICT        scsi0:3.deviceType = scsi-hardDisk

There are some old/orphaned entries for already removed virtual disks!? However, this should not cause the issue.

Mar 25 21:13:06.212: vmx| SNAPSHOT: SnapshotBranch failed: Change tracking target file already exists (5).

This one is what I think is related to the issue. To me it looks like there was an issue once with changed block tracking, which may have left any orphans. What I would do is to first delete any .ctk files in the VM's folder on the datastore (they will be recreated, only the next incremental/differential backup will take more time). If this does not help you could try to - at least temporarily - disable CBT for the VM or remove the VM from the inventory, delete the .ctk files and then add it to the inventory again..

André

View solution in original post

0 Kudos
4 Replies
a_p_
Leadership
Leadership
Jump to solution

Please post (attach) the VM's vmware.log file. This should show what's going on.

André

0 Kudos
iohr
Contributor
Contributor
Jump to solution

I've tried to strip out sensitive information like hostnames. I hope this hasn't garbled the file.

0 Kudos
a_p_
Leadership
Leadership
Jump to solution

The file names are correct since there's an active snapshot on the VM. I found a few entries in the log file which we/you could check:

Mar 23 08:01:25.543: vmx| DICT        scsi0:2.deviceType = scsi-hardDisk
Mar 23 08:01:25.543: vmx| DICT        scsi0:3.deviceType = scsi-hardDisk

There are some old/orphaned entries for already removed virtual disks!? However, this should not cause the issue.

Mar 25 21:13:06.212: vmx| SNAPSHOT: SnapshotBranch failed: Change tracking target file already exists (5).

This one is what I think is related to the issue. To me it looks like there was an issue once with changed block tracking, which may have left any orphans. What I would do is to first delete any .ctk files in the VM's folder on the datastore (they will be recreated, only the next incremental/differential backup will take more time). If this does not help you could try to - at least temporarily - disable CBT for the VM or remove the VM from the inventory, delete the .ctk files and then add it to the inventory again..

André

0 Kudos
iohr
Contributor
Contributor
Jump to solution

I found the following ctk files and renamed the with a .bak on the end of the filename, (just being cautious):

  • ourvmname-ctk.vmdk
  • ourvmname-000002-ctk.vmdk
  • ourvmname_1-ctk.vmdk
  • ourvmname_1-000005-ctk.vmdk
  • ourvmname_1-000001-ctk.vmdk

After this I have done a manual snapshot of the VM using the vSphere Client. It completed!Smiley Happy

Thank you so much for an acurate and very rapid response.

Ian

0 Kudos