CBT reset on Active full and different storage Repo

[zxzxzxzxzx]

We are currently doing a POC with a new storage repo and noticed that when an active full is done with a CBT reset on the new repo and there is an old snapshot present, it will stun the VM for a few minutes.

When we do the same active full and the job resets the CBT data there is no stun when we use our existing storage Repo. Is this because the old storage repo technically knows about it already?

I know veeam doesn’t recommend a snapshot present during an active full and CBT reset, but wonder how we have been getting around this for so long with the old repo. I am thinking maybe the original job (with CBT reset) was created before the snapshot was made, the new job was made after the snapshot was made ( even though it was a clone of the original job?)

We see in the job that it is resetting CBT in both scenarios, but its hanging on creating snapshot ( around 7 minutes ) - The original job lists the snapshot creation time as being 0sec, but the job is completing sucessfully..

[Gostev]

VM snapshot creation process (which in particular involves VM stun which should normally be just some milliseconds) is completely outside of our control as the whole operation is performed by the ESXi host in response to CreateSnapshot API call issued by Veeam. It is a black box for us and nothing on the Veeam side can possibly affect this process, certainly not the type of backup storage in particular. If you observe excessively long VM stuns then you should open a support case with VMware and have them review hypervisor logs to find the root cause.

[Andreas Neufert]

You can maybe try to reproduce and test a bit on your own by just going into vcenter and creating and deleting snapshots there directly without Veeam involvement . This maybe helps to nail down the issue.