agent unable to save configuration to disk: Error syncing firmware configuration: vim.fault.TooManyWrites

[xbradshr]

I took a host(host 10) out of maintenence mode. Another host(host 14) vmotioned a couple of VMs to it. The vmotion process stopped progressing, and the following error was recorded on host 10: agent unable to save configuration to disk: Error syncing firmware configuration: vim.fault.TooManyWrites

The management agents later failed on host 14, and it lost connection to vcenter, plus the vmotion aborted. One of my co workers was able to get host 14 working again, after running

esxcfg-rescan vmhba32 and services.sh restart

Other VMs vmotioned okay to host 10, while two did not. what kind of issues can cause the vim.fault.toomanywrites condition?

Vcenter had the following suggestions:

Possible causes:

Cause: The agent cannot send heartbeats because of a networking related failure on host

Cause: The agent failed to update the configuration file on host

Cause: The agent failed to save the configuration file to disk on host

Cause: The provisioning module failed to load. As a result, all provisioning operations will fail on host.

ESXI version is 4.1.0, 260247

Any suggestions for checks appreciated.

[DataSpar]

Interesting.. I just had a client experience the same conditions. The ESXi (5.0 U1) servers randomly disconnected from vCenter (typically after only a few minutes of being connected). We also had the vim.fault.toomanywrites error in our vCenter logs, which is how I stubled across this post. It seems that error is caused by a lot of different things.

After trying all the normal things (reading countless logs, rebooting everything, talking to the servers nicely, banging head against keyboard...), we finally found the soluton to our problem.  Windows Firewall on the vCenter server was blocking the communications.  Once we disabled the firewall, everything worked.

For a more permanent (and secure) solution, add the appropriate firewall exceptions as noted in KB 1012382:

http://kb.vmware.com/selfservice/microsites/microsite.do?cmd=displayKC&docType=kc&externalId=1012382...

Hope this helps someone.

-Brian

[fourg]

Encountered this same error with one ESXi 5.5 host and vCenter 6.0.  The problem ended up being that UDP port 902 was getting blocked inbound by our firewall to vCenter from this specific host.  Logs showed every minute a UDP packet would get blocked until we opened it up and the host was instantly happy again.