Three (important) things you might not know about the vmkiscsid.log file

• Matt Liebowitz
• August 25, 2010March 6, 2011
• 2
• 1014

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.