Really just posting this for someone else who gets this weird error
This is a good one!
Running Symantec BE2010 R3 all hotfixes (according to live update)
Vcenter 4.1.0 258902
ESXi 4.1.0 502767
2003 SP2 32 bit
2003 R2 SP2 64 Bit
VM Tools 8.3.12
In the BE log get the "usual error"
"The job failed with the following error: Unable to create a snapshot of the virtual machine. The virtual machine may be too busy to quiesce to take the snapshot"
In the VMWare log - "A general system error occurred: Protocol error from VMX."
Yet the machines that gets the error in the log can snapshot with quiesce in VCenter fine.
For some reason , when the backups run on these two machines (many more on the host ), their times move ahead 8 hours and the backup fails
If I re-run they backup job immediately, the time is still 8 hours ahead so the backup works.
If I retry after the time has been reset, the job will fail again
The time stays forward for the duration of the backup job.
I am not sure if the time is reset at the end of the job or that a standard windows time sync resets it.
The resolution was to check the Host. Its time was set 8 hours ahead.
EVEN THO the VM Tools client was set NOT to update time from host
A snapshot in vCenter with Quisce, worked fine. It was only when thet backup was run that the error occurred
Stange but true catergory
I know this thread is a few days old, but here goes:
You say you can snapshot with quiesce just fine using vCenter... You did uncheck the "Snapshot virtual machine's memory" when testing this right?
I do believe that this option is excluded when your backup software hits the vStorage API to take a snap before backup....
Even though that the VMware Tools isn't configured to sync time with the host, it still happens during snaps, migrations etc... You do have an option to disable this.. http://kb.vmware.com/kb/1189
Thanks for the reply Rubeck,
No i did not uncheck snapshot memory when creating a snapshot via vcenter, thank you for that.
And also thanks to the link to the total disabling of the time sync. I was not aware of that.
FWIW, we would never do what was suggested, it is much easier to set the time correctly on the host in the first place