Three (important) things you might not know about the vmkiscsid.log file
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.
More vSphere 4.1 Enhancements – Welcome Back PVSCSI Driver!
As I keep digging into documents and KB articles I keep finding more and more things to like about vSphere 4.1. Today's find has to do with the PVSCSI driver.
With the release of vSphere 4.0, VMware added a new paravirtualized SCSI driver into the VMware Tools that provides better virtual disk performance than the standard LSI driver. The PVSCSI driver promised to deliver better performance and lower overall CPU utilization for workloads that had high I/O demands. Unfortunately the PVSCSI driver wasn't supported on virtual machine boot volumes, so folks held off on making this the default SCSI driver for all virtual machines.
After vSphere 4 Update 1 was released, VMware lifted the restriction and now supported the PVSCSI driver on boot volumes. Folks began considering adopting the PVSCSI driver in all virtual machines similar to how the VMXNET driver is a standard for nearly all virtual NICs. Soon afterwards VMware came out with a knowledgebase article stating that virtual machines that did not have heavy I/O demands could actually experience worse performance using the PVSCSI driver. They recommended only using the driver for workloads that had I/O demands in excess of 2,000 IOPS.
With the release of vSphere 4.1 that is no longer a problem and you can use the PVSCSI driver in all circumstances. Want details? Read on!
Nice Addition to vSphere 4.1 Enterprise License
When vSphere 4.1 was released a lot of people were talking about all of the amazing new features available in the product. Along with introducing many new features, VMware also shuffled around some existing features into different license levels. The one that got the most press was that vMotion was now available in vSphere Standard as well as the Essentials Plus bundle.
In my opinion one of the biggest changes isn't being talked about much at all. In vSphere 4.1, VMware has made the use of 3rd party multipathing plug-ins available in vSphere Enterprise edition and higher. In vSphere 4 this was only available in the Enterprise Plus license, making it out of reach for smaller customers.
This link compares the features available in vSphere 4.1 and it states that vStorage APIs for Multipathing are supported in both Enterprise and Enterprise Plus. Multipathing plug-ins like EMC's PowerPath/VE and Dell's new EqualLogic Multipathing Extension Module allow you to have better integration and control over multipathing than VMware's native multipathing plugins. I challenge you to say multipathing more times in one sentence than I just did.
The other really important point about VMware making this feature available in the Enterprise license is the likelihood that the Enterprise license will persist going forward. VMware had originally planned on phasing out the Enterprise license in favor of Enterprise Plus but backed down on that plan after customer complaints. They stated at the time that they expected sales of Enterprise to decrease over time as customers purchased Enterprise Plus. Taking a feature from Enterprise Plus and making it available in Enterprise shows, at least to me, a commitment to keep that license level around for the foreseeable future.
vMotion of clustered VMs is supported in vSphere 4.1..or is it?
While looking over some of the new vSphere 4.1 documentation I noticed that VMware had updated their Setup for Failover Clustering and Microsoft Cluster Service document. As clustering becomes a bigger component of Microsoft's enterprise applications, support for clustering in vSphere becomes even more important.
As in previous versions of this document they list the limitations for clustering on vSphere. The list of limitation is below:
The following environments and functions are not supported for MSCS setups with this release of vSphere:
Migration with vMotion of clustered virtual machines.
Issues updating VMware Tools with Update Manager
I recently updated a lab environment to vSphere 4 Update 2 and wanted to upgrade VMware Tools on several VMs at once. I decided to use Update Manager to push out the VMware Tools update, and during the process discovered an issue between Update Manager and newer versions of Windows. I didn't try any of the following with vSphere 4.1.
I remediated a folder of about seven VMs and to my surprise I saw that only a few of them actually updated. The others simply sat there and never updated the tools, rebooted, or did much of anything. Sorting the folder by Guest OS I noticed something - all of the VMs that did not update were running either Windows Server 2008 or Windows 7.
Welcome to thelowercasew.com!
Hi and welcome to thelowercasew.com! After blogging for Kraft Kennedy's blog (my employer) for the past year and a half I decided to start blogging on my own. I'll be writing for both blogs at the same time so I'll try to keep the content fresh in both places and do my best to entertain and educate. And getting some sleep once in a while would be nice..
You can read all about me in the About section. Also don't be surprised if you see the look and feel of the blog change as I'm still deciding on themes, widgets, and all other WordPress goodness. I hope you stick around, add this blog to your RSS feeds, and post a comment or two.
Thanks for visiting!
Recent Posts
- Three (important) things you might not know about the vmkiscsid.log file
- More vSphere 4.1 Enhancements – Welcome Back PVSCSI Driver!
- Nice Addition to vSphere 4.1 Enterprise License
- vMotion of clustered VMs is supported in vSphere 4.1..or is it?
Recent Comments
- Kevin C on More vSphere 4.1 Enhancements – Welcome Back PVSCSI Driver!
- Scott Sauer on More vSphere 4.1 Enhancements – Welcome Back PVSCSI Driver!
- Andrew Storrs on More vSphere 4.1 Enhancements – Welcome Back PVSCSI Driver!
- Matt on Issues updating VMware Tools with Update Manager