I was in a conversation with one of my pals over at Tintri last week (Fintan), and he observed some strange behaviour when provisioning VMs from a catalog in vCloud Director (vCD). When he disabled Fast Provisioning, he expected that provisioning further VMs from the catalog would still be offloaded via the VAAI-NAS plugin. All the ESXi hosts have the VAAI-NAS plugin from Tintri installed. However, it seems that the provisioning/cloning operation was not being offloaded to the array, and the ESXi hosts resources were being used for the operation instead. Deployments of VMs from the catalogs were taking minutes rather than seconds. What was going on?
I was involved in some conversations recently on how the VAAI UNMAP command behaved, and what were the characteristics which affected its performance. For those of you who do not know, UNMAP is our mechanism for reclaiming dead or stranded space from thinly provisioned VMFS volumes. Prior to this capability, the ESXi host had no way of informing the storage array that the space that was being previously consumed by a particular VM or file is no longer in use. This meant that the array thought that more space was being consumed than was actually the case. UNMAP, part of the vSphere APIs for Array Integration, enables administrators to overcome tho challenge by telling the array that these blocks on a thin provisioned volume are no longer in use and that they can be reclaimed.
I’m sure Frank Denneman will need no introduction to many of you reading this article. Frank & I both worked in the technical marketing organization at VMware, before Frank moved on to PernixData last year and I moved to Integration Engineering here at VMware. PernixData FVP 1.0 released last year, and I did a short post on them here. I’d seen a number of people discussing new FVP features in the community, especially after PernixData’s co-founder Satyam’s presentation at Tech Field Day 5 (#TFD5). I decided to reach out to Frank, and see if he could spare some time to revisit some of the new features that PernixData is planning to introduce. Fortunately, he did. I started by asking Frank about how PernixData is doing in general, before moving onto the new bits.
I’ve been doing a bit of work over the past number of weeks on the adapters for vCenter Operations (vC OPs) with my old pal Paudie. We are working on vCenter Operations 5.8 and using a vSphere 5.5U1 environment. Since we have a Brocade Fibre Channel switch and an EMC VNX array in our lab, I wanted to get the Management Pack for Storage Devices (MPSD) and the Brocade SAN Analytics Management Pack deployed, and see what information we could glean from those extension packs. When we completed the configuration, we were able to go into the vC OPs customs view and see details like the following Brocade – Health Overview and Storage Components Heatmap:
Caution: We spent a lot of time trying to figure out why the MPSD adapter would not connect to the CIMOM service on Brocade’s Network Advisor. This boiled down to networking/DNS configuration issues. The MPSD release notes for vC OPs describe the issue. As they say, I should have RTFM. Anyhow, here are the steps we went through to get this setup going. I’m afraid it is rather long, but hopefully you will find the information in here useful.
Pure Storage are all over the news at the moment. They just secured another round of funding (225 million to be precise), and are now valued at over 3 billion. You can read more about that here. However, even before this announcement, I had already arranged to have a catch up chat with Pure’s primary evangelist (and a good pal of mine), Vaughn Stewart. I was surprised to see that it had been 18 months since I last did a piece on Pure so I really did want to see what changes they had made in the meantime as there were a few vSphere interoperability pieces still to be completed when we last spoke.
I watched a very cool demonstration this morning from the All Flash Array vendor, SolidFire. I spoke with SolidFire at the end of last year, and did a blog post about them here. One of the most interesting parts of our conversation last year was how SolidFire’s QoS feature and VMware’s Storage I/O Control (SIOC) feature could inter-operate. In a nutshell, QoS work at the datastore/volume layer whereas SIOC deals with the VM/VMDK layer. Last week, Aaron Delp and Adam Carter of SolidFire did an introduction to QoS, both on vSphere and on the SolidFire system. And they also did one of the coolest demos that I’d seen in some time, namely how they have managed to get SIOC and QoS to work in tandem.
Continuing on my set of posts related to Virtual SAN (VSAN) interoperability, let’s take a look at how vCenter Operations Manager (vC Ops for short) integrates with Virtual SAN. vC Ops version 5.8, which was released in December 2013, recognizes the VSAN datastore and can report various characteristics, as you might expect. Although vC Ops 5.8 was released around 3 months before VSAN GA’ed, this release works with ESXi 5.5U1 and vCenter 5.5U1, the vSphere release which introduced VSAN. However, this release of vC Ops does not present all the ‘storage’ metrics for VSAN like it does for datastores based on other storage types. But, having said that, there are still a number of useful vC Ops views and metrics that you might find useful which this post will cover.