Forum Discussion

Bexhill_IT's avatar
Bexhill_IT
Level 3
10 years ago
Solved

BE2010 R3 and ESX 5.1.0 2583090

Hello all

Since upgrading to ESX 5.1 and R3 of BE 2010 we have had great difficulty backing up some VMs. I have seen similar problems posted here and elsewhere but can't seem to get to the bottom of our issue.

When running backups we are getting the error 'An attempt to take a snapshot of a virtual machine failed because it was unable to quiesce an application.'

This seems to be fairly common and I have tried the suggested advice about remote agents and VSS writers etc. with no success.

I have found that if I test the resource credentials for the job and then run it manually, then it works. Sometimes I have to do this twice before it will work but it does eventually back up.

However when it is next run as a scheduled job, it fails with the same error.

I can supply further info as requested, but I was hoping this problem/solution would be sufficiently weird for somebody to recognise it and save me from spening out of hours time beating VM backups into submission.

 

 

  • First, start off with this KB - https://www.veritas.com/support/en_US/article.TECH129724

    Then isolate which VMs are producing this error. Are these VMs which have Application GRT enabled ?

  • Thanks for reply

    This is pretty much where I came into the process. I have checked all the things it suggests and all seems to be in order.

    We are not enabling GRT backups.

    It seems that most VMs are experiencing the problem but as I say I am not really changing any settings, I am just rerunning and it decides to work after an attempt or two.

  • Thanks for reply

    It looks like 2583090 is the latest version of U3 and so that is probably the root of our problem.

    BE15 here we come.

  • Cool, just grab manual copies of the Data/Catalogs folders before doing the upgrade, and then run LiveUpdate to get the latest patches before push-installing them if required.

    Thanks!

  • The quiesce error relate to how VMware tools makes a request to VSS inside the individual VMs and teh feedback (or timeout erros) that are returned by the process. Hence it can be worth looking in the event logs (or vssadmin statuses) inside each VM to see if there are issues inside the VM themselves.

    I's also recommend disabling any scheduled shadow copy requests against the volmes inside the VMs (and remove saved shadow copies) and also make sure you are not keeping lots of Vmware snapshots (in the vSphere Snapshot manager) Basically existing snapshots could cause a performance issue which then cause a timeout to be exceeded.

  • Funnily enough, it was looking at the remote machine event log which lead me to the 'solution' of validating the credentials. I will have another look to see if anything else pops out at me.

    Thanks.