VM crashes after backup snapshot consolidation – name issue?

[janezk]

Hi,

We have a VM, that was unexpectedly shut down, after backup (with warnings), but snapshot consolidation looks like it failed and messed the configuration file .vmx. It pointed the VM HDD to file »WINVM-000003.vmdk« that didn't exist. There were files with numbers -000001, -000002 and -000004.
However that would be kind a normal, if our VM's name would't be »WINVM-000001« . I know that VMWare is using the extension -000001 for snapshots. But i never saw that such naming would be not recomended.

Is there an odd chance, that during the snapshot consolidation performed by Veeam when finishing the backup, that somehow last part of original name of VM was mistaken for the first snapshot. And when consolidation failed, Veeam created new snapshot »WINVM-000002« and then also 3 and 4 and then it all ended with misconfigured . vmx file and with lock on original VM file »WINVM-000001.vmdk«
Has anyone ever encountered a problem like this (or are we the first winners…) ?

Additional info:
- After unlocking the files, we were able to import the VM back to VC and after reconfiguration of the disks using the original file »WINVM000001.vmdk«, it started and is working normally.
- I performed a restore from the last backup and I got out files WINVM-000001.nvram, .vmdk, .vmx, .vmxf and WINVM-000001-flat.vmdk, that has a size of the 60GB, and was also able to do a FLR, so the backup is obiously in consistent state.
- We didn't open a support case... we are still gathering all the info
- And please don't ask me how in the world we choose a »lucky« name like this…

BR Janez

[foggy]

Janez, what kind of warnings did that backup job have? Basically, snapshot consolidation is performed by VMware itself, Veeam B&R is just issuing an API call to it asking to do that, so honestly it is hard to comment on what could go wrong on that side.

[larry]

The ESX server that holds the vm has the vmx file locked. Reboot the host that holds the VM will fix it. If needed move other VMs to other hosts.

[Lotus101]

We have just encountered a similar issue when performing backups on servers that have virtual disks larger than 2 TB. The backup would complete, but consolidation of the snapshots would fail resulting in locked files which would shut down the servers due to the locked files. Veeam stated the consolidation was performed by VMware, but after snapshot creation and consolidation testing done directly in Vmware, those completed normally. Disk consolidation is not completely done by Vmware. After extensive testing by Vmware and us, we believe the problem to be with Veeam, but they are to this day still blaming the issue on Vmware.

Up until September 28, backups of these machines were functioning normally. The only way we could resolve this was to create logical disks using virtual disks smaller than 2 TB and spanning. There is still no resolution to this issue.

We are running Veeam version 9.5.0.1038 and VMware 6.0 full patched.

[foggy]

Please share your support case ID. Veeam B&R is not involved in snapshots consolidation process apart from issuing the corresponding calls to VMware, so I suggest escalating the case for further investigation, unless done already.

[Apples]

Hi Lotus101, did you ever resolve your issue? We have exactly the same problem, ours was created when we extended a disk over 2TB. We've upgraded to VMware 6.5 and are also running Veeam 9.5.0.1038