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:
Same if I want to create a new one:
But what if I want to create a new virtual disk independently of a VM? Maybe create a new disk, copy a volume on my array to it that has a SQL database on it and provision that (or a copy of it) as necessary to other VMs? This is why VMware introduced “first class disks”.
See Cormac’s post here:
William Lam posted about the APIs introduced in 6.5 to manage a FCD here:
For examples in this post, I will use PowerCLI. Instead of the new-harddisk cmdlet, you use new-vdisk instead–this allows you to create a virtual disk without specifying a VM.
Creating a FCD with VVols
Let’s create our first VVol FCD!
First I want to grab my datastore:
This is of course a VVol datastore. Now I can create my new FCD with new-vdisk.
Specify a name, a size, a format, and of course a datastore. So in the VVol datastore, we see a new folder called FCD:
The VMDK file appears in there. Since it is VVols, the VMDK is just a pointer to a volume on the array. So on the FlashArray we see two things. A new volume group and the volume.
The volume group has FCD in the name and we can see my 4 TB disk. We also see the config VVol that is created which hosts the pointers in the FCD folders.
Of course feel free to rename the volume group or data VVols (volumes)
I will work on some PowerShell cmdlets to automate this, so stay tuned on that front.
If I create another one in that datastore, it will go into the same volume group:
Anyways, sweet! Now we can query for FCDs with get-vdisk
What else can you do? Well there are a few other PowerCLI cmdlets:
So resizing, copying, deleting, moving, etc. The common things.
I think this make for some interesting use cases–like the idea of a VMDK template. A FCD that has a copy of a SQL database for instance–it can be created and stored there, and new virtual disks can be copied from it or refreshed from it. Can you do this with VVols and standard virtual disks? Yes of course–but it needs to be associated with a VM for VMware to really manage it, or managed directly on the array. Doing this allows a VVol virtual disk to be a first-class object not only on the array, but also within VMware.
Because VVols on the FlashArray can be copied instantly, refreshed instantly etc, I think the combination of the two achieve what was really meant by first class disks by VMware.
So if I have a FCD that I called sqlprod-6-7-2019:
So I can take that and copy it out to a new FCD:
Then we can add it to a VM:
Snapshots and FCDs
Another interesting use case for FCDs is snapshots. This allows the virtual disk and the snapshots to exist outside of a VM as well. There are three interesting APIs:
One note, the snapshot APIs are only available in vSphere 6.7+, so you do need to be on the version for this to work.
What I do not see is a direct PowerCLI cmdlet for them–so I am still doing some testing around that. But, you can still totally do it with our trusty friend get-view.
$serviceInstance = Get-View ServiceInstance
$vStorageMgr = Get-View $serviceInstance.content.VStorageObjectManager
The above APIs can be run from there. So to create a new snapshot, you need three things, the vDisk ID, the datastore moRef and a description.
In the VVol datastore you will see a snapshot pointer VMDK now:
So using the other APIs you can either create a new FCD via the original source or even one of its snapshots! So if it is in use, you can create a single snapshot of the data VVol and then spawn copies from it.
On the array, if you associate that VVol with a VM, you can move it for reporting/management purposes to the volume group of the target VM:
There is a lot more to dig into here, so watch out for more blogs on this topic–I think there is a lot of opportunity here for VVols.