Three (important) things you might not know about the vmkiscsid.log file
- Matt Liebowitz
- 2
- 1013
While working on an issue for a client recently I discovered a few things about the vmkiscsid.log file that I didn’t know. I thought I’d share them in case others didn’t know this information.
The vmkiscsid.log file, located in /var/log on your ESX host, maintains information and errors about iSCSI connections. We had a problem with our SANs where a NIC flapping issue caused errors to be written to that log file on a regular basis. That problem was resolved with a SAN firmware upgrade and things returned to normal.
While looking into another issue I noticed that the /var partition had filled up on all of the hosts (you’re creating separate /var partitions for ESX installs, right….?). Taking a closer look revealed that the vmkiscsid.log file had grown to 3.7GB on all of the hosts before running out of space on /var. In the process of troubleshooting this situation, I learned a few important things about this log file.
1) The vmkiscsid.log file does not use automatic log rotation like other log files.
2) The vmkiscsid.log file is automatically deleted and recreated at bootup.
3) You cannot simply delete the vmkiscsid.log file to reclaim space on the partition. You must reboot.
I spoke with VMware support about this and a feature request has been created so that the log file does automatically rotate. For now I was told the only way to clear it is to reboot the host.
Is this something you need to be concerned about? Probably not – in most cases this log file remains very small and won’t present a problem. It’s likely only to be a problem if you’re experiencing persistent problems with an iSCSI connection.
Update 11/10/2010: VMware has released a Knowledge Base article that address the behavior I described above. They describe a process of looking for open files that have the deleted vmkiscsid.log file locked. For what it’s worth I tried to go down this road and wasn’t able to find the file so a reboot was necessary for me.
Update 3/6/2011: VMware Support sent me an email saying that they’re going to change this behavior in vSphere 4.0 Update 3. The logs will now use automatic log rotation(.1, .2, etc) just like other log files. There was no mention of when this will make it to vSphere 4.1, but I assume it will be included in the next update.
2 thoughts on “Three (important) things you might not know about the vmkiscsid.log file”
Leave a Reply Cancel reply
This site uses Akismet to reduce spam. Learn how your comment data is processed.
Is there something special you have to do to an ESX host to get the vmkiscsid.log file to start getting generated? I have an ESX 4.1 host on the latest update, attached to some iSCSI storage, and no matter what I do, I do not see this log file anywhere on the host.
I’ve tried inserting the “option.LogLevel” by running the vmkiscsid with the -x parameter. Also tried various log levels, including 999. Tried rebooting the host. Tried running rescans.
Nothing I do makes this log file appear, including deliberately inducing errors such as disconnecting a target port. I see the “dead” status appear in the Vsphere client, but still no log file.
I’m baffled. Any ideas? Thanks!
To be honest I’m not sure – I’ve seen it on all ESX hosts with iSCSI storage. You’re looking in /var/log, right?