Ramdisk Full Esxi Direct

esxcli system settings advanced set -o /Scratch/ConfigCurrentScratchLocation -s "/vmfs/volumes/datastore1/.scratch" esxcli system settings advanced set -o /Scratch/ConfigureScratch -i 1 After reboot, logs and temp data move off ramdisk. Forward logs to a remote server to reduce local ramdisk pressure.

Hostd.ERROR: Failed to write to /var/run/vmware/hostd/hostd.log: No space left on device 4.1 Check Ramdisk Usage Access ESXi shell (SSH or DCUI) and run: ramdisk full esxi

esxcli system syslog config set --loghost='udp://10.1.1.100:514' esxcli system syslog reload Increase rotation frequency and reduce retained size. Edit /etc/vmware/hostd/config.xml : Edit /etc/vmware/hostd/config

<logLevel>info</logLevel> <logMaxSizeKB>2048</logMaxSizeKB> <logMaxFiles>3</logMaxFiles> Check for enabled debug flags: It directly threatens host manageability and VM stability

esxcli system settings advanced list | grep -i debug Set unnecessary ones to 0. For /tmp only (resets on reboot):

mount -o remount,size=2048M /tmp | Practice | Benefit | |----------|---------| | Always provision local VMFS or high-speed datastore for scratch | Eliminates ramdisk use for scratch data | | Deploy vRealize Log Insight or syslog server | Offloads all logs from host | | Monitor /var/log usage via vCenter alarms | Early warning before full condition | | Use ephemeral VMs for intensive logging tests | Isolates log noise | | Keep ESXi patched | Many ramdisk leaks fixed in updates (e.g., log4j-related flooding) | 8. Conclusion The "Ramdisk full" condition on ESXi is not a memory capacity issue but a transient storage exhaustion problem. It directly threatens host manageability and VM stability. While immediate truncation of logs and restart of services can provide relief, the permanent solution lies in moving transient data off the ramdisk via persistent scratch and remote logging. Proactive monitoring of vdf -h as part of routine health checks is essential for ESXi environments of any scale. For VMware support, always collect vm-support before cleaning the ramdisk to preserve forensic data.

vdf -h Look for filesystems with tmpfs or visorfs and Use% approaching 100%. Typical mount points: /tmp , /var/log , /var/run , /scratch du -sh /var/log/* | sort -hr | head -20 du -sh /tmp/* | sort -hr | head -20 find /var/run -type f -size +50M -exec ls -lh {} \; 4.3 Check Scratch Configuration esxcli system settings advanced get -o /Scratch/ConfigCurrentScratchLocation If empty or points to a non-existent path, scratch is using ramdisk. 4.4 Monitor Ramdisk Growth in Real Time watch -n 2 'df -h /var/log /tmp' 5. Immediate Remediation (Without Reboot) | Step | Action | Command | |------|--------|---------| | 1 | Stop the offending service (if log flood) | /etc/init.d/hostd stop (careful – impacts management) | | 2 | Truncate large log files (instead of delete) | echo "" > /var/log/hostd.log | | 3 | Remove stale core dumps | rm -f /var/core/* | | 4 | Kill large transient VMX temp files | Identify via lsof /tmp and terminate VM if needed | | 5 | Restart management agents | services.sh restart | Caution: Deleting system files in /var/run or /tmp may require restarting services to recreate expected socket files. 6. Permanent Solutions 6.1 Configure Persistent Scratch Partition Set a dedicated scratch location on a persistent datastore (local or shared).