After a reboot of a server, it can happen that it is not possible to take a quiesced snapshot.It happened after an update to 6U1 from 6.0. Before the update there were no problems.
We did the following to troubleshoot the problem.
* Reinstall VMWare Tools
* Check VSS Providers for errors (no errors)
What we found out was that it can happen after a reboot of the server and only if the service "VMware Snapshot Provider" is running (service is set to manual). To correct it we need to stop "VMware Snapshot Provider" and "VMware Tools". If all is stable, ie no running services, which should not run, like "Volume Shadow Copy" we start the service "VMware Tools". After this we can take a quiesced snapshot again.
While this ain't a huge problem, it is annoying at best. Any one have a solution or have the same problem.
We are seeing this to for 6U2 for Windows 2012 R2 and Windows 2008 VM's.
We are using VSC 6 as a backupsolution.
In the Windows VM's eventviewer we can see: A timeout (3000 miliseconds) was reached while waiting for a transacation response from the VMTools service).
So when it trying to quiece the Windows Guest it stops the VMwareTools service and the quiceing fails.
VSC /SMVI backuplogs does not give anything.
One thing that are kind of weird is that it's not for all VM's. It is just for some.
But the problem seems like the one we discussing here.
Have there been any updates regarding this from VMware?
veeam 9 ur 2
vmware 6.0.0. 382559
I found random behaviour amongst guests (server 2012 R2) with this
I found the vmware snapshot provider running (set to manual) after reboot
I stopped the service
I re-ran the veeam job and it was successful
I had this issue with vmware tools 10.1.x. I opened a case with vmware and this is a know issue. See Quiesced snapshots of Windows 2012/2012R2 VMs with Tools 10.1.0 fails (2149640) | VMware KB for the workarround.
I was dealing with similar issues with Commvault and VMware snapshots for server 2012r2 on 6.0u2 . Stopping the vmware service prior to backup resolved the issue. I have a pre-backup script that runs in commvault to resolve this issue.
Another solution if youre using commvault , is to use Intellesnap. This takes the snap a the block level and the Guest is never touched.
"Another solution if youre using commvault , is to use Intellesnap. This takes the snap a the block level and the Guest is never touched."
I do not quite agree.... Even when using IntelliSnap a VM snap is still performed prior to the hardware snap... You can ofc still choose to quiesce it or not.
I have faced the same issue in my Virtual Infra and worked with VMware Technical support the same, below is what they suggests and it resolved the issue:
Make Sure To Follow All the steps:
To resolve this issue, start the Windows Virtual Disk service:
services.msc, and press Enter.
If this does not resolve the issue, disable VMware snapshot provider in the affected virtual machine:
We solved the issue by stopping the services (VMware snapshot provider and volume shadow copy) after a reboot.
The problem seems to be resolved after update to VMware 6.5U1 though.
Hope this helps anyone. Thanks all for your reply.
As a first step, upgrade the VMware Tools version to 10.2.5. Below is the download link -
If the above does not help, kindly follow the below steps -
- To resolve this issue, start the Windows Virtual Disk service:
1) Log in to the Windows operating system as an Administrator.
2) Click Start, type services.msc, and press Enter.
3) Right-click the Virtual Disk service and click Start.
- If this does not resolve the issue, disable VMware snapshot provider in the affected virtual machine:
1) Disable the VMware Snapshot provider service in the guest operating system.
2) Restart the Volume shadow copy service.
This is happening to a few of our 2016 MS servers and the only option that seems to allow a quiesced backup is disabling the VMware Snapshot Provider service.
I have read that the best practice is to set this VMware service to manual but that causes the quiesced snapshot to fail every time.
Is there an issue with disabling this service.