VMware Employee
VMware Employee

VSS not stable in VM

One of Windows Administrator reported that VSS is not stable in VM but stable in Physical Machine with same OS running in Physical or Virtual Machine. Anyone has any idea about this.

Regards, Ranjna Aggarwal
0 Kudos
3 Replies
Hot Shot
Hot Shot

Can we get more information? Would something be using VSS on VMs versus the physical? Like for example, is Veeam or a storage vendor's backup application using VSS? Can you give us the error messages either in event viewer (if there is any) and also run : vssadmin list writers to see which ones are errored out?

New blog - https://virtualizeme.org/
0 Kudos


We need more information about your VMware configuration :

ESXi version ?

How many host have u ?

have you update physical host drivers ?

Have you an VMware vcenter infrastructure ?

Can u privide log ?

have you this problem with others VMs on the same VSS ?



0 Kudos

We are using TSM4VE to backup our VMs. ( that include Windows and Linux ).

We are not using this for very large VMs, instead we use a local backup agent inside each of these.

But for all other that are backed up with TSM4VE and use VSS quiescing...

The only thing we see that can be causing issues that could come from VSS is some VMs randomly have a quiescing error, so the backup fail for these VM.

This is very random, and from what we see up until now we have observed the following.:

1- If the vmtools are out of date, it looks like that can sometime cause the VSS to become corrupted or we need to re-run the install / update tools so it re-register the VSS component with VMtools as stated in the VMware KBs.

2- There is also some post and VMware support that mentioned that high IO usage while trying to create a quiesced snapshot can cause the quiescing to fail, so we try to monitor this.

But just to give you an idea, we backup 500+ VMs using this on our 2 sites, and we have around 10-15 failures daily ( which 0-5 are VSS (quiescing ) issue ).

Other are not related to VSS.

Re-running manual backup for the failed one, seem to be always working, so for me it kind of point more toward the #2 reason since when re-running at different time manually do not throw a quescing issue.

We currently work to have those fixed.

Note: Also we have updated our backup software to use the latest vddk, because there was a lot of known issues / fix in the previous one we were using. so you may want to validate which verssion will be in use before and make the appropriate update to reduce the change of errors.