Unable to release guest. Details:VSSControl: Failed to freez

[rmehta]

support case ID: 01715929
I keep getting this warning only on replication job. We manage backups are replication for different customers, and all the customers are configured following way.
a. Replication job targets a different data store however uses the same VCENTER cluster.
b. Backup job which triggers after replication is complete.

both the jobs have application aware processing enabled however we often get this warning only on exchange machines with different customers although the subsequent backup job runs fine
"Unable to release guest. Details: VSSControl: Failed to freeze guest, wait timeout "

Although VEEAM support has asked for the VM specs like memory, free disk space etc, I suspect it not to be a VM issue. I had run the disk shadow command and the snapshot gets created without any error and also during the backup job everything runs fine. Having a hard time getting this resolved

[foggy]

Are there any related messages in the VM guest OS Event Viewer?

[alanbolte]

As described in https://www.veeam.com/kb1377 and https://www.veeam.com/kb1680, this is most commonly due to creation of the VMware snapshot taking longer than 20 seconds. If that is the problem you face, we have a built-in workaround, but it has some limitations:

• The VM runs Microsoft Exchange 2010, Microsoft Exchange 2013 or Microsoft Exchange 2016.
• The VM does not perform the role of a domain controller.
• Microsoft Exchange databases and log files are located on a non-system disk of the VM.

If VMware snapshot creation time (strictly speaking, a combination of VMware snapshot creation and certain in-guest operations that are usually fast) is greater than 20 seconds, and you cannot meet the requirements for persistent snapshots, you will have to work with VMware and your storage vendor to improve VMware snapshot creation time.

[rmehta]

Thanks alan: the exchange databases are stored in system volume; however, the backup runs fine on the server and it is configured to run just after the replication. I also noticed that the snapshot gets created before 20 seconds in logs

eventviwer log states
source: ESE
ShadowCopy instance 21 aborted.

this happens after the event source ESE
Information Store ShadowCopy freeze ended

so it appears that the snapshot completes...

[foggy]

Then please continue working with your engineer, closer review of the log files is required.

[rmehta]

As described before, I have replication job running first and then the backup job, in the application aware processing, I had "truncate logs" disabled on the replication job as the backup job runs next, however, I enabled this option yesterday just to check, and no replication warning today; and the backup job has run fine as well. however, I am skeptic to keep this setting as the restore from the backup would not have logs incase someone wants to roll back to a specific time.

[foggy]

As described before, I have replication job running first and then the backup job, in the application aware processing, I had "truncate logs" disabled on the replication job as the backup job runs next, however, I enabled this option yesterday just to check, and no replication warning today

This looks unexpected as when there's an active job that performs transaction logs backup (had done that within last 7 days, actually), all other jobs will be prevented from touching them.

[alanbolte]

Is it possible to connect from your backup server to these VMs over the network, or only via networkless (VIX API) communication? VIX can add significant delays. For example, if it takes 17 seconds to create the VMware snapshot, but VIX spends 3+ seconds transferring commands (from your backup server, to the vCenter, to the host, to guest), that can cause this error. I've seen VIX add 30 seconds even in environments that otherwise perform acceptably.

[rmehta]

received a call from 3rd level, ran a snaphost on the VMs, took more than 30 seconds, was advised to either
a. upgrade vmware to 6.0
b. try changing the datastore of the vm