Despite having it on my “to-do” list for quite some time, I still haven’t configured vSphere Autodeploy. Instead, I’ve written scripts to automate most of the settings that I need to apply. I’ve felt like this has mostly sufficed and enabled me to still quickly provision a host.
Not long ago I deployed a new host and neglected to provision storage properly – I never entitled this host to the datastore where I was storing my host logs. I didn’t catch this because I still haven’t learned how to properly handle errors in my PowerCLI code (it’s an action item for me). This meant that my log directory couldn’t be set properly but my modifications to log retention were successful. The end result was a host with the error message: “The ramdisk ‘root’ is full.”
I ran a quick line of PowerCLI to check my hosts for their logging directoy:
Get-VMHost | Get-AdvancedSetting Syslog.global.logdir | Select Entity, Value
I found the host in question had not set the directory correctly. I reset the log directory with some quick PowerCLI.
Get-VMHost $vmhostname | Get-AdvancedSetting Syslog.global.logdir | Set-AdvancedSetting –Value “[DatastoreValue] log” –confirm:$false
Awesome – my host is up to date. Now to fix my ramdisk issue. I opened SSH to my host and ran a quick df -h but found that none of my space was filled.
Instead, I ran vdf -h and found what I was looking for. Notice that, according to the errors in the first screenshot, the ramdisk ‘root’ is full.
Updating my log rotation size had quickly filled /scratch/log which filled up the ramdisk – I have to imagine that this happened quickly after I had provisioned the host. 32M isn’t exactly a ton of data.
After removing all of the log-related items from the root directory, I again checked my vdf -h and found the ramdisk had freed up.
No further issues on this host!
So how did you remove all of the log-related items from the root directory?
Hi, Dan –
It’s been a while since I ran into this, but I know that my logs were writing to /scratch/log which at the time was in the ramdisk. In my scenario, I simply deleted the logs. Assuming you have an alternate location, I’d say you can likely move them instead of delete them if there’s a need to review the logs themselves.
Hope that helps!
-James
Thanks for the quick reply (especially since it was a 2018 article!)… I was mistaking “root” as a folder. I looked in the error logs and found which folder\files that couldn’t be written which led me to oversized logs I could clear out with the > command. I’ll monitor for growth and look into alternative locations for the files that tend to get too big or find the setting to limit the number of entries.Great article, got me moving in the right direction.
Dan