Think about what that means for a second.
It means that you now get virtual disk granularity of VMs for not only data services on the array, like snapshots, clones, and replication – but you also get virtual disk granularity for replication. You’re no longer forced to snapshot/clone/replicate entire datastores, or dealing with pesky, slow SCSI bus rescans and even more painful datastore resignature operations.
For a technical introduction to VVols, go ahead and watch this playlist with videos from my coworker and VMware extraordinaire, Cody Hosterman. Keep reading after for a discussion on running SQL Server workloads on VVols.
Done with the videos? Cool. If not, make sure you watch them later – they have the best explanation of how VVols work that I’ve seen out there. And even if you don’t use FlashArray, the explanation and concepts apply (mostly) the same.
SQL Server on VVols: The Good, The Bad, and The Ugly
Did I scare you with the title? Sorry, that was meant to throw you off.
Repeat after me: VVOLS SHOULD BE YOUR FIRST CHOICE FOR VIRTUALIZING SQL SERVER ON TOP OF VMWARE VSPHERE, PERIOD.
With VVols, you maintain the performance of an RDM with the agility of a VMDK. No more worrying about thin vs eager zero thick or any of that nonsense!.
Moving between physical volumes, RDMs and VVols is extremely straightforward on FlashArray. A move to VVols from VMFS basically entails a simple storage vMotion, which on FlashArray is an array deferred, metadata-only operation. Since FlashArray is a data reducing array, a storage vMotion from VMFS to VVols is just a VAAI XCOPY operation. Your new “copy” will only consume a little bit of space for the metadata, and nothing else. An RDM to VVols migration is also pretty straightforward, and there’s no VMFS datastore “container” to worry about. It’s exactly the same layout on the array, whether you go physical, RDM, or VVols. And you’re not “stuck” with VVols once you make the decision to go down that route for a given virtual disk. If you need to go back to VMFS, just storage vMotion it back, simple as that.
When Can I NOT Use VVols Then?
There is only one scenario where you can’t quite use VVols for SQL Server, and that’s when you have shared storage between SQL Server instances, which is the case for Failover Cluster Instances (FCI), which you probably just call “clusters” and VMware keeps calling “MSCS” (for Microsoft Cluster Server), which is nomenclature from 2003, feels like 1989, and no one should be using anymore.
However, there’s good news on that front! VMware will support SCSI-3 reservations on VVols starting with version 6.7, which is slated for release early next year. Go ahead and read Eric Seibert’s blog post on VVols futures for more information on that. At that point, I don’t want any of you even mentioning VMFS to me, unless you’re running a version of vSphere prior to 6.5 (which is our requirement for VVols). But quite honestly, VVols is a pretty compelling reason to upgrade to 6.5, or 6.7 when it comes out!
