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). As per the Oracle press release, “Support for these APIs will help simplify VMware customer access to the higher levels of performance and efficiency available with ZFS Storage Appliance and Pillar Axiom storage systems.” Read the full press release from Oracle here.
Nutanix just announced the availability of NOS 3.5. It has been approximately 6 months since I posted about their NOS 3.0 release which had a lot of cool features. I was curious to see what they added to 3.5, especially from a VMware integration perspective.
This is something which has come up numerous times, and behavior which many of you have observed. There seems to be some issue with uploading files to a VMFS datastore. In fact, in one example, we had someone report that it took 10 minutes to upload a Windows 7 ISO to an iSCSI datastore and less than 1 minute to upload the same ISO to an NFS datastore. Both datastores were very healthy and fast, and both had running VMs on them. There have been variations of this behavior reported before. This post will try to explain why.
This is something that was recently brought to my attention, and I wasn’t aware of this difference in behavior between the various storage vendors who implement VAAI-NAS. VAAI-NAS implements a number of different offload primitives, but the one we are interested in here is the Fast File Clone primitive which is the ability to offload the creation of snapshots/clones to the NAS storage array. This mechanism is also referred to as Native Snapshots. However, some arrays cannot support a full chain of snapshots.
I’ve blogged about the VMFS heap situation numerous times now already. However, a question that I frequently get asked is what actual happens when heap runs out? I thought I’d put together a short article explaining the symptoms one would see when there is no VMFS heap left on an ESXi host. Thanks once again to my good friend and colleague, Paudie O’Riordan, for sharing his support experiences with me on this matter – “together we win”, right Paud?
I just got a notification about this myself today. Apparently there is some interoperability issues with VAAI (vSphere APIs for Array Integration) & EMC RecoverPoint on EMC VNX arrays. It looks like the VNX Storage Processor (SP) may reboot with Operating Environment Release 32 P204 in a RecoverPoint environment. EMC have just released today a technical advisory – ETA emc327099 – which describes the issue in more detail but is basically advising customers to disable VAAI on all ESXi hosts in the RecoverPoint environment while they figure this out. Hopefully it won’t take too long to come up with a…