Applies to: All versions
Sometimes an "Application consistent" snapshot may fail for different reasons.
When that happens you will find details by taking a look at the snapshot history, something similar to the screenshot below:
As you can see, the snapshot has been taken, but instead of "Application consistent" it is "Crash consistent".
To find out why this has happened we need to log in to the ESXi host and find additional information on the "Host" -> "Monitor" -> "Tasks".
Below you can see an example:
To continue troubleshooting the cause of the issue it is necessary to view the virtual machine's event log. Usually, the most relevant information can be found in the guest OS Event Viewer (Windows).
An example in the screenshot below:
Note: the purpose of the examples presented above is to define a troubleshooting workflow when an "Application consistent" snapshot failed.
The details may not apply in your specific situation.
The following articles provide information to identify and troubleshoot most common situations, as documented by VMware.
- When quiescing a guest operating system using the Microsoft Volume Shadow Copy Service (VSS) prior to a snapshot, the operation fails. Troubleshooting Volume Shadow Copy (VSS) quiesce related issues: Pleago to see this article
- When a quiesced snapshot is created on a Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, or a Windows Server 2012 R2 virtual machine, duplicate disks are created in the virtual machine. Creating a quiesced snapshot of a Windows virtual machine generates Event IDs 50, 57, 137, 140, 157, or 12289. Pleago to see this article
- Cannot create a quiesced snapshot of a virtual machine if other backup tools (Symantec BackupExec, Veeam ecc.) are installed within the virtual machine. Pleago to see this article
Note: The Distributed Transaction Coordinator service must be running while installing VMware Tools. Otherwise, VSS fails to quiesce Windows 2008 R2/ WIndows 2012.