We just got notification about a potential issue with the VAAI UNMAP primitive when used on EMC VMAX storage systems with Enginuity version 5876.159.102 or later. It seems that during an ESXi reboot, or during a device ATTACH operation, the ESXi may report corruption. The following is an overview of the details found in EMC KB 184320. Other symptoms include vCenter operations on virtual machines fail to complete and the following errors might be found in the VMkernel logs:
My good pal Duco Jaspars pinged me earlier this week about an issue that was getting a lot of discussion in the VMware community. Duco also pointed me to a blog post by Andreas Peetz where he described the issue in detail here.
The symptom is that the ESXi hostd process becomes unresponsive when software iSCSI is enabled. There is another symptom where an ESXi boot hangs after message “iscsi_vmk loaded successfully” or “vmkibft loaded successfully”. This has only been only observed with the ESXi 5.5 U1 Driver Rollup ISO. It has not been reported by customers using the standard ESXi 5.5U1 media. The VMware ESXi 5.5 Update 1 Driver Rollup provides an installable ESXi ISO image that includes drivers for various products produced by VMware partners.
Initially it was reported in the community that it appeared to be an issue with the Diablo TeraDimm driver that was shipped as part of the roll-up. However further investigation has concluded that the Emulex be2iscsi driver is at fault and is the root cause. VMware support are recommending that you use an updated be2iscsi driver as per KB article 2075171 to address the issue.
So for those of you that plan a 5.5U1 deployment and also use software iSCSI, heads up if you plan on using the ESXi 5.5U1 Driver Rollup ISO (which is only supported for use with new installs by the way, and not upgrades).
I thought it might be useful to share some of the various VM Storage Policy status that I have observed whilst testing Virtual SAN (VSAN). I’m sure this is by no means a complete list but as I said, these are the ones that I have come across and I am sure these are the status that you will observe most often too.
At this stage, VSAN has only been in GA for a number of weeks, even though many of us here at VMware have been working on it for a year or two (or even more). Sometimes when we get into explaining the details of storage objects, components, etc, we forget that this is all so new for so many people. In a recent post, someone asked me to explain the concept of a witness on VSAN. Looking back over my posts, I was surprised to realize that I hadn’t already explained it. That is the purpose of this post – explain what a witness disk is in VSAN, and what role it provides.
I was going to make this part 11 of my vSphere 5.5 Storage Enhancements series, but I thought that since this is such a major enhancement to storage in vSphere 5.5, I’d put a little more focus on it. vFRC, short for vSphere Flash Read Cache, is a mechanism whereby the read operations of your virtual machine are accelerated by using an SSD or a PCIe flash device to cache the disk blocks of the application running in the Guest OS of your virtual machine. Now, rather than going to magnetic disk to read a block of data, the data can be retrieved from a flash cache layer to improve performance and lower latency. This is commonly known as write-through cache, as opposed to write-back cache, where the write operation is acknowledged when the block of data enters the cache layer.
I’ve been presenting at a number of conferences over the past number of weeks/months, both internal and external. While a lot of my sessions have focused around Virtual SAN (VSAN), I got a number of questions around whether or not the new Software Defined Storage product from EMC, ViPR, competes with or complements Virtual SAN. Since ViPR 1.0 is now available (since September), and a new release of ViPR is due out before the end of the year, I thought I’d take a closer look at what ViPR is all about and try to answer that question.
Before I left for PTO, I wrote an article on a number of different storage vendors you should be checking out at this year’s VMworld 2013. One of these was a new start-up called PernixData. With tongue firmly in cheek, I suggested that PernixData might use VMworld as a launchpad of their FVP (Flash Virtual Platform) product. Well, needless to say, my good friend Satyam Vaghani, CTO at PernixData, reached out to me to say that they were in fact announcing FVP before VMworld. He shared some details with me, which I can now share with you if you haven’t heard about the announcement.