Edit /etc/vmware/logrotate.conf – ensure these parameters exist for vmafdd:
In rare cases, the token cache stored by vmafdd becomes corrupt. The daemon attempts to read the cache, fails, attempts to refresh it, fails again, and logs the entire lifecycle each time. This can occur after an improper host reboot or an abrupt vCenter upgrade.
Typing du -sh /var/log/vmafdd.log only to see a result of 10 GB, 20 GB, or even more is a startling experience. This seemingly minor log file can spiral out of control, consuming precious space on the ESXi root filesystem (which is typically only 4–10 GB for the boot bank). When this happens, your hypervisor can become unstable, VMs may fail to start, and core management functions (like vCenter communication) can break. vmafdd.log too big
If you are a VMware administrator, you have likely encountered the dreaded "disk full" alert on an ESXi host, only to trace the culprit back to a single, bloated file: .
/etc/init.d/vmafdd start tail -f /var/log/vmafdd.log Edit /etc/vmware/logrotate
/var/log/vmafdd.log size 100M rotate 10 compress missingok notifempty postrotate systemctl reload vmafdd endscript
This stops the process so you can safely handle the log. Typing du -sh /var/log/vmafdd
size=$(du -m /var/log/vmafdd.log | cut -f1) if [ $size -gt 500 ]; then echo "CRITICAL: vmafdd.log too big ($size MB)"; fi
Every few seconds, vmafdd attempts to request a token. Because the time is wrong, the SSL/TLS certificate validation fails. The daemon logs a full stack trace of the error, retries, fails again, and logs again. This infinite loop writes megabytes of data per minute.