One of the major advantages we have seen with VVols is making a virtual disk a first class citizen on the array. We can restore, copy, replicate them (and their VMs) as storage objects were meant to be restored, copied, replicated etc.
Though one thing about virtual disks is that by default–they are not first class citizens in vSphere, VVols or otherwise. To create one, it has to be associated with a VM.
To retrieve one in PowerCLI (for example) get-harddisk requires a datastore or a VM to return a result:
This post is somewhat specific to Pure Storage–the cmdlets of course are universal, but behaviors may not correlate to your storage array. So if you are using VVols on a non-Pure array, certainly consult your vendor.
Furthermore, this is certainly specific to PowerCLI when it comes to the commands. With that being said, the fundamentals on how this works with Pure is common for all orchestration tools, so you should be able to use this information for other tools. Though of course the cmds/syntax will be different.
The FlashArray implementation of Virtual Volumes surfaces VMs on the FlashArray as standard volume groups. The volume group being named by the virtual machine name. Each VVol is then added and removed to the volume group as they are provisioned or deleted. These objects though are fairly flexible–we do not use the volume group as a unique identifier of the virtual machine–internally we use key/value tags for that.
The benefit of that design is that you can delete the volume groups, rename them, or add and remove other volumes to it. Giving you some flexibility to group related VMs or whatever your use case might be to move things around, without breaking our VVol implementation.
This post I will talk about using PowerCLI to run a test failover for VVol-based virtual machines. One of the many nice things about VVols is that in the VASA 3.0 API this process is largely automated for you. The SRM-like workflow of a test failover is included–so the amount of storage-related PowerShell you have to manually write is fairly minimal.
One of the first technical benefits users can enjoy around VVols is the use of snapshotting. Snapshots created through VMware of VMs have always been a point of contention which as severely limited their usability (see a post I did around the performance impact of them here).
With VVols, when you right-click on a VM and choose take snapshot, VMware does not create the performance-impacting delta VMDK files that were traditionally used, but instead VMware entirely offloads this process to the array. So the array creates the snapshots and VMware just tracks them.
But since VMs are now a collection of individual volumes on the array (a VVol is just an array volume) you can also snapshot and restore individual virtual disks as well directly on the array.
VVols have been gaining quite a bit of traction of late, which has been great to see. I truly believe it solves a lot of problems that were traditionally faced in VMware environments and infrastructures in general. With that being said, as things get adopted at scale, a few people inevitably run into some problems setting it up.
The main issues have revolved around the fact that VVols are presented and configured in a different way then VMFS, so when someone runs into an issue, they often do not know exactly where to start.
The issues usually come down to one of the following places:
One of the great benefits of VVols is that fact that virtual disks are just volumes on your array. So this means if you want to do some data management with your virtual disks, you just need to work directly on the volume that corresponds to it.
The question is what virtual disk corresponds to what volume on what array?
Well some of that question is very array dependent (are you using Pure Storage or something else). But the first steps are always the same. Let’s start there for the good of the order.
At the Pure//Accelerate conference this year, my colleague Barkz and I gave a session on data mobility–how the FlashArray enables you to put your data where you want it. The session video can be found here: