Some time ago, I hooked our Virtual Volume (VVol) capable storage array up to a vSphere 6.5 cluster. I did a few preliminary tests, such as adding the VASA (vSphere APIs for Storage Awareness) Provider, creating the VVol datastore, observing the creation of the Protocol Endpoints (PEs), and of course creating some virtual machines as a set of VVols. All went flawlessly. Then, like many other lab tests, I got distracted by a number of other things. In the meantime, the storage array vendor announced support for an updated VASA version, and we had the storage array updated to accommodate…
Today VMware unveils vSphere version 6.7, which also includes a new version of vSAN. In this post, I am going to highlight some of the big-ticket items that are in vSphere 6.7 from a core storage perspective, and also some of the new feature that you will find in vSAN 6.7. I’ll also cover some of the new enhancements coming in Virtual Volumes (VVols).
Hot on the heels on Pure Storage’s recent announcement on Virtual Volume (VVol) support, I wanted to take a closer look at their VVol implementation for myself. Thanks to the support team over at Pure, they were able to very quickly update our lab array to the latest release that has support for VVols. Once this upgrade was complete (which was all done remotely), I wanted to go ahead and register the VASA provider with my vCenter server. You can read more about the role of VASA here. I wanted to step through the process manually, rather than use the…
Last week I had the opportunity to drop down to San Jose and catch up with our friends on the FlashSoft team at SanDisk. In case you were not aware, this team has been developing a cache acceleration I/O filter as part of the VAIO program (VAIO is short for vSphere APIs for I/O Filters). SanDisk were also one of the design partners chosen by VMware for VAIO. This program allows for our partners to plug directly into the VM I/O path, and add third-party data services, such as replication, encryption, quality of service and so on. An interesting observation…
With the release of vSphere 6.0 earlier this year, VMware introduced the eagerly anticipated VVols or Virtual Volumes. As we see more and more traction around VVols, a specific question has come up a number of times already. The question is basically: “What happens to VVols if I lose my VASA Provider or my vCenter Server, or indeed both of these components? Will I still have access to my devices?”.
Regular readers will know that I normally blog about the technical aspects of storage, as opposed to doing opinion pieces. However there have been a number of articles published recently questioning the value of VMware’s Virtual Volumes, commonly referred to as VVols. In general, the pieces I have read ask whether or not VVols (or to be more accurate, per-VM granularity feature of VVols) adds value when NFS is already doing per-VM granularity in the form of files. The point that was missed in these pieces is that VVols is so much more than per-VM granularity. I’ve just come back…
A short post today, but it highlights what I feel is an important enhancement to vSphere licensing. I’ve had lots of questions recently about why VAAI (Storage APIs for Array Integration) is not available in the standard edition of vSphere. This is especially true since I began posting about Virtual Volumes earlier this year, and it was clear that Virtual Volumes is available in the standard edition. One reason why this was confusing is that if a migration of a VVol could not be handled by the array using the VASA APIs, the migration would fall back to using VAAI…