Hello there
Hope someone can help
I'm trying to deploy a VM from template and it comes up with error below
I have done a vdf -h on host and I can see that this is due to MAINSYS being at 100%. 32mb out of 32mb used
I followed a few KB articles that deal with deleting 'sel' and 'sel.raw' from /var/log/ipmi/0 but issue persists. When through everything in here http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=200145... but to no luck
Anyone has any advise or suggestions. Which partitions fall under MAINSYS to check those directories for large files on them
Many thanks
Petrit
When you say, the issue persists, do you mean the files come back, the MAINSYS is 100% again? Or you mean you still have the problem of not being able to deploy the template?
I assume you restarted the sfdbd service after removing the files?
I mean I still can't deploy templates
Bear in mind the files 'sel' and 'sel.raw' were very small in KBs, so issue could be somewhere else. I did restart sfcdb
What would really help is to know what directories ammount and help with MAINSYS becoming full so that I can go to those directories and see what is taking the most space
Any other ideas would be highly appreciated it
Did you check this KB for what files are "safe" to delete when needed? http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=100356...
Maybe you can find more tips on where to look for what is eating the diskspace.
Deleting unnecessary files
The following are a list of files that are safe to delete:
- Old vm-support log bundles.
- Virtual machines that are not being used and are not needed.
- Old log files that are no longer needed.
- Virtual machine log files can be removed if there are a large number (thousands) of
vmware*.log
files in the virtual machine's folder. For more information, see Too many vmware.log files created on VMFS datastores results in delays or failure to power on virtua....- ISO files that were copied to the system.
Caution: Do not delete the VMware Tools ISO files from/vmimages/.
After you have determined what is consuming disk space, delete the unnecessary files:
- Open a console to the ESX or ESXi host. For more information, see Unable to connect to an ESX host using Secure Shell (SSH) (1003807) or Using Tech Support Mode in ESXi 4.1 and 5.0 (1017910).
- Use the
rm
command to permanently delete files. For example:rm /var/log/oldlogfile
Caution: If you delete a file, there is no way to recover it. Therefore, use caution when deleting files. If you are unsure about deleting a specific file, contact VMware Support for assistance. If a system file is removed inadvertently, it may cause damage to your ESX or ESXi host that can require a re-installation of the software.
[edit] especially this command can give you interesting results:
du -h --max-depth=1 <dir>
. This command lists the directories within a given filesystem that contain the largest files. By starting at the root (/) directory and finding the largest directories, you can then drill down into these directories (using cd) and execute the same command recursively until you find the files themselves which are occupying space.
Right,
Just got off the phone with the nice people at VMware Support.The nice guy was John O'Brien
Issue is this:
/var/log/arcconf.log had increased in size to 28mb out of 32. (It took 7 weeks to go to 28mb) 'arc' in the file stands for Adaptec Raid Controller. The solution for now is to zero out the file with echo. so, echo > /var/log/arconf.log
The longterm solution for is that we created a crontab job which deletes the arcconf.log every week. For how to do that follow this:http://blog.armstrongconsulting.com/?cat=1 under heading "Unable to start VMs on ESXi 5.1" obviously applies to 4.1 as was my case
John will write up a KB and follow with Adaptec on the issue, hopefully
Thanks spravtek anyway
Petrit
Hi,
That's a nice solution there
Thanks for getting back to us with it!