Specify VSS Provider for VMware Backups

[arctics2]

We have been having an issue where backups of VMware VM's will fail with a status 156.  After some troubleshooting, we came up with a workaround where we disable the VMware Snapshot Provider service (vmvss) thereby forcing the system to use Microsoft VSS. 

This works, however, as I understand the process, when Netbackup sends a request to vmware tools to quiesce the OS, it specifies that vmware tools should use whatever is configured as the default VSS provider.  By default, the default appears to be vmvss.  When vmvss is disabled, it fails over to vss. 

My question is, can Netbackup be configured to specify which VSS provider to use without installing the Netbackup VSS provider agent on every VM?  It appears as though other Backup vendors provide the ability to specify this (https://forums.veeam.com/post180042.html?hilit=vss%20provider#p180042)

Thanks

[Michael_G_Ander]

If you disable the vmvss, vmware does not call the VSS inside the VM, it should be the same as doing a snapshot without checking the quiesce file system from vsphere.

In my opionion it is better to solve the issue with the VSS system that is causing the 156, as you then get a more consistent backup and better chance at a working machine after recovery.

[Michal_Mikulik1]

Hello,

you cannot specify this - VM snapshotting is under control of VMware. The article you are pointing to seems to be related to some volume-level backups, not VM-level backups.

Michal

[arctics2]

Thanks for the responses. 

Michael, are you saying that when we disable vmvss, then take a quiesced snapshot, it's not actually quescing anything and that this is the same as just taking a non-quiesced snapshot??

[arctics2]

Further to both of your points, I agree that the underlying issue with vmvss needs to be resolved, however, before going back to the vmware team, I need proof that this is not a misconfiguration on the backup application side.

[Michael_G_Ander]

In my experience these errors is most often caused by a problem with the VSS system inside the VM, so I would go to the OS administrator of the VM first.

Unfortunately not all VSS issues can be seen in the event logs, but a very common problem is a too small shadow area on some disks or/and failed VSS writers