Earlier this month I had the opportunity to meet with a number of VMware customers in both Singapore and in the UAE. Most of the sessions were enablement and education type sessions, where there was a lot of white-boarding of VSAN (VMware’s hyper-converged infrastructure product) and Virtual Volumes (VVols – Software Defined Storage or SDS for the storage arrays). This wasn’t a sales session; I’m not in sales. The objective of these sessions was simply to educate. I guess when you are immersed in this stuff 24×7, it easy to fall into the trap of believing that everyone is well…
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…
I had a very interesting query in my recent VVol post on vSphere HA interop. In that post I showed how the VVol datastore could be used for datastore heartbeating. The question then arose when the VVol datastore could be used for other things, such as a syslog and scratch destination. I couldn’t see any reason why not, but just to be sure, I tested it out in the lab. The quick answer is yes, you can use a Config-VVol for syslog, and no, you cannot use a Config-VVol for scratch. If you want to see the steps involved, and…
I had a few queries recently on how Virtual Volumes (VVols) worked with vSphere HA. In particular, I had a number of questions around whether or not VVol datastores could be used as a heartbeat datastore by vSphere HA. The answer is yes, the VVol datastore can be used for vSphere HA datastore heartbeating. If you want to see how, please read on. I think these queries may have arisen due to the fact that we do not use datastore heartbeating with Virtual SAN (VSAN). Just by way of reminder, the master host in a vSphere HA cluster uses a…
There have been a number of queries around Virtual Volumes (VVols) and replication, especially since the release of KB article 2112039 which details all the interoperability aspects of VVols. In Q1 of the KB, the question is asked “Which VMware Products are interoperable with Virtual Volumes (VVols)?” The response includes “VMware vSphere Replication 6.0.x”. In Q2 of the KB, the question is asked “Which VMware Products are currently NOT interoperable with Virtual Volumes (VVols)?” The response includes “VMware Site Recovery Manager (SRM) 5.x to 6.0.x” In Q4 of the KB, the question is asked “Which VMware vSphere 6.0.x features are…
In some previous posts, I highlighted how VVols introduces the concept of “undo” format snapshots where the VM is always running on the base disk. I also mentioned that this has a direct impact on the way that we do snapshots on VMs that support VSS, the Microsoft Volume Shadow Copy Service. But before getting into the detail regarding how VVols is different, it’s worth spending some time understanding whats going on when VSS is called to quiesce applications when a traditional snapshot is taken. If you try to research this yourself, you’ll find that there is very little information…