I thought it was about time that I looked at some of the larger storage vendors closer to home. One of these is of course Bull. This company is probably more familiar to those of us based in Europe rather than those of you based in the Americas or Asia Pacific. However VMware customers in EMEA will have seen them in the Solutions Exchange at VMworld Europe, where they have a reasonably large presence. After some conversation with my good pal Didier Pironet, whom I’ve met at a couple of recent VMUGs, I was introduced to Philippe Reynier who is a manager in the Bull StorWay Competence Center and Solution Center. Philippe provided me with a lot of good detail on Bull’s storage solutions which I will share with you here.
There are many occasions where the information displayed in the vSphere client is not sufficient to display all relevant information about a particular storage device, or indeed to troubleshoot problems related to a storage device. The purpose of this post is to explain some of the most often used ESXCLI commands that I use when trying to determine storage device information, and to troubleshoot a particular device.
I was discussing this issue with a good friend of mine over at Tintri, Fintan Comyns. Fintan was seeing some strange behaviour with the cloning on Windows 2008 R2 Guest OS running in virtual machines using the Tintri VAAI-NAS plugin, and wanted to know if this behaviour was normal or not. Basically what he was seeing was that a clone operation of a virtual machine was not being offloaded. Rather, he was seeing two separate independent snapshots (snapshots that were not in a chain, but both pointing to the base VMDK) were getting created at the time of the cloning operation. Fintan also reported that if they used to the Sync Driver or stopped VMware Tools altogether in the Windows 2008 R2 Guest OS, the operation worked and the clone operation was being offloaded. The same operation was tried with a Windows 7 Guest OS running in a virtual machine, and in this case a single snapshot was created which was offloaded. so what was going on? It had us scratching our heads for a while.
All Flash Arrays continue to make the news. Whether it is EMC’s XtremIO launch or Violin Memory’s current market woes, there is no doubt that AFAs continue to generate a lot of interest. Those of you interested in flash storage will not need an introduction to SolidFire. These guys were founded by Dave Wright (ex-RackSpace) and have been around since 2009. I have been trying to catch up with SolidFire for sometime as I’d heard their pitch around Quality of Service on a per volume basis and wanted to learn more, especially how it integrated with vSphere features. Recently I caught up with Dave Cahill and Adam Carter of SolidFire to have a chat about SolidFire in general and what the VMware integration points are.
Continuing on the series of vSphere 5.5 Storage Enhancements, we now come to a feature that is close to many people’s hearts. The vSphere Storage API for Array Integration (VAAI) UNMAP primitive reclaims dead or stranded space on a thinly provisioned VMFS volume, something that we could not do before this primitive came into existence. However, it has a long and somewhat checkered history. Let me share the timeline with you before I get into what improvements we made in vSphere 5.5.
A short note to let you know about some interesting news for Oracle/VMware customers. Oracle has just announced that it has licensed a number of VMware vSphere Storage APIs, including VMware vSphere API for Array Integration (VAAI), VMware vSphere API for Storage Awareness (VASA) and VMware vCenter Site Recovery Manager (SRM).