TDPVE Backup Failure Due to VSS Issue

dcharles226

ADSM.ORG Member
Joined
Apr 2, 2015
Messages
37
Reaction score
1
Points
0
Hello,

I'm not sure if this question has been asked before, and I'm getting conflicting answers while googling.

We are running TSM Server 7.1.1 on Red Hat 6.2 with TSM VE 7.1.1 on CentOS 6.5 backing up a multitude of Windows and Linux VMs.
We have 30 VMs backing up fine on a schedule we created using the TSM VE gui. However, when we try to add some new VMs to back up, or even if we run a normal backup using command line, we are getting the following issue:

11/17/2015 07:24:05 ANS9365E VMware vStorage API error for virtual machine 'Server03'.
TSM function name : CreateSnapshot_USCORETask
TSM file : vmvisdk.cpp (5259)
API return code : 1939
API error message : An error occurred while quiescing the virtual machine. See the virtual machine's event log for details.
11/17/2015 07:24:05 ANS2712W The virtual machine 'Server03' has a VMware Tools running, but VMware Tools is out of date.

11/17/2015 07:24:05 ANS5250E An unexpected error was encountered.
TSM function name : vmVddkFullVMPrePareToOpenVMDKs
TSM function : snapshot targetMoRefP is null
TSM return code : 115
TSM file : vmbackvddk.cpp (12419)
11/17/2015 07:24:05 ANS1228E Sending of object 'Server03' failed.
11/17/2015 07:24:05 ANS4015E Error processing 'Server03': unexpected TSM error (115) encountered

Now, I can get the backup to work, but only if I update the VMware Tools on the target VM, and remove the Volume Shadow Copy Services Support feature.

I figure that this issue is caused by a conflict between VSS Services in VMware Tools, but it doesn't happen on all of our VMs.

Not sure if anyone else has encountered this issue, or if I have made an incorrect configuration change somewhere.

Thanks in advance for your help.
 
Thank you for the quick response. We will look into these options and provide any updates if they help.

Thanks again!
 
So we determined:

1) That the ntp services is indeed running on all of our ESXi boxes

2) That we do not have any Volume Shadow Copying running on the target VMs.

There must be another reason that this is happening.
 
Back
Top