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.

So what does all of this mean?

First off, there are two “types” of snapshots when it comes to VVols:

• Managed snapshots. This is what is created when you initiate a snapshot of a VM that is using VVols via a VMware interface (the vSphere Web Client, PowerCLI, vRO, etc). This process creates array-based snapshots that VMware “knows” about.
• Unmanaged snapshots. These are snapshots of a VVol that are created by anything else besides VMware. So log into your array GUI and snapshot a volume that is in use as a VVol of a given VM. Since VMware didn’t create it, it doesn’t know about it and that is referred to as an unmanaged snapshot (VMware doesn’t manage it).

So let’s walk through these options in more detail. This post will focus on the use of managed snapshots and what they mean for VVols. I will expand on unmanaged snapshots in subsequent posts.

Creating Managed Snapshots

If you want a deeper dive on how redirection works or quiescing you can go to Cormac’s excellent post here:

https://cormachogan.com/2015/03/10/virtual-volumes-a-new-way-of-doing-snapshots/

No reason for me to rewrite all of that.

A major benefit for VVols with the FlashArray is that snapshots are now FlashArray volume copies, which are globally data reduced (so their footprint is quite small), metadata based (so their creation, restore from and deletion is instantaneous) and are not copy-on-write (so no performance impact).

So how does this actually look?

Well here I have a VM with two virtual disks, one 50 GB one and one 1 TB disk.

Since this is a VVol-based VM, these virtual disks are actually volumes on the array. If I jump over to the FlashArray GUI, I can find the volume group that matches that VM:

Inside of that volume group are all of the VVols that are assigned to that VM, This VM happens to have four VVols:

• One config VVol (see this post for what that is)
• Two data VVols. One for each virtual disk. 50 GB and 1 TB.
• One swap VVol. When the VM is powered on a swap VVol is created (sized to the memory assigned to that VM) and is deleted when it is powered off.

We can also note that there are no snapshots on the FlashArray at this time:

If we flip back to the vSphere Web Client, and choose Manage Snapshots:

We can see that there are no listed VMware snapshots.

So let’s create one!

As I mentioned any VMware-based tool will create a VMware managed snapshot. The vSphere Web Client, as I will show, or for instance with PowerCLI with the new-snapshot cmdlet.

If I click on the VM, then Snapshots then Take Snapshot…

…a familiar screen pops up:

I have three options here:

1. Snapshot the VM and its memory (default)
2. Quiesce the guest file system
3. Or choose no options

For instructional purposes I will choose option three, where I select no options. More on the other options later.

Click OK.

A few things happen here. If you go to the Manage Snapshots screen in the vSphere Web Client, you will see the snapshot you created.

You can now restore from it or delete it. But what happened on the array?

Let’s take a look. Back in the volume group, the snapshot pane now lists two snapshots:

One for each data VVol. So when you take a VMware managed snapshot, VMware actually tells the array to create a snapshot of each data VVol–so there is a point-in-time of every virtual disk (remember virtual disk = data VVol).

You will note that the config VVol is not snapshotted. There is no real need for that as the configuration information for the snapshot is actually stored in the config VVol itself. So in other words, VMware backs up the configuration of the VM in the configuration VVol. (there is a use case for snapshotting a config VVol manually, but that is for another blog post).

The swap VVol is also spared because there is zero need to snapshot that–there is no persistent data there.

How are the other options different? What if instead of doing no options like above I went with the default (storing the memory state)?

Note that this option is only available if the VM is powered-on.

When the snapshot is created, you can see it like normal in the Manage Snapshots window in the vSphere Web Client.

You can see that the selected snapshot is a memory snapshot in the details pane on the right as shown by the above arrow.

On the FlashArray we see the same thing: two snapshots, one for each virtual disk/data VVol:

But there is also another VVol–a memory VVol. This is created when you choose the memory snapshot option–the memory state is stored in the memory VVol.

When you choose the quiesce guest option, the memory state is not stored, but VMware tools will quiesce the file systems inside of the guest for a file system-consistent snapshot.

Using the quiesce option requires that the VM be powered-on and VMware tools to be installed in the VM.

This option is somewhere in the middle of the other two. It does not store the memory state, but it does attempt to quiesce the file systems in the VM first. So from an array perspective it looks the same as no options selected–a snapshot of each data VVol is created.

Restoring from Managed Snapshots

So how do you restore from a managed snapshot?

This is no different than what you did with VMFS or NFS. The process to create is the same and so is the process to restore.

Click on the VM, then Snapshots, then Manage Snapshots. Select the snapshot you want and click Revert To.

Confirm it.

No matter what type of managed snapshot, this will always first power-off the VM when you click OK. This is because it is discarding the current state and reverting to the selected point-in-time.

So what happens on the array? Well in the case of this VM, there is a 50 GB virtual disk and a 1 TB one. VMware first powers-off the VM and then tells the array to revert each disk from a certain snapshot. The FlashArray then does a volume copy from the snapshot to the volume that is the data VVol. This is just a metadata copy on the FlashArray so it is instantaneous.

Once the process is complete you can power-on the VM. This will then boot the OS using the point-in-time of that snapshot–but remember that a VM using VVols is never running from the snapshot! It always still running from the data VVol. The data on the data VVol has just be overwritten from that snapshot to revert it to that time.

If the snapshot you are reverting to includes a memory VVol, the VM will actually be powered-on after the operation–this is because not only are the data VVols restored to their point in time, so is the memory. So the VM is reverted back to the exact state of when the VM was snapshotted–the applications that were running etc.

Deleting a Managed Snapshot

Deleting a managed snapshot is no different than what you are used to either. To do so, right-click on your VM and choose Snapshots then Manage Snapshots.

Find your snapshot and click the Delete button. This will remove the references to the snapshots and also remove them from the array. 

Please note–do not delete the snapshots from the array directly if they are “managed” snapshots. Always use VMware to delete these snapshots–just like with VMFS or NFS, you should not go to the file system and delete snapshot VMDK files manually–you should use the vSphere snapshot interface to delete them.

Additional Benefits

So overall–things seem pretty similar to regular VMware snapshots right? Wrong! There are a lot of benefits here:

• Performance–traditional software-based VMware snapshots hurt performance a variety of places. When you created them the latency was impacted due to the creation of new files and the movement of new I/O to the new delta VMDK. Furthermore the mere existence of the snapshots hurt latency. This is because the running state of the VM now ran off of the snapshot and there was some impact there in general. But more because the re-direction (I/Os may go to the source snapshot like reads to unchanged portions, or may go to the new delta VMDK like new writes, or reads to changed portions). Furthermore the deletion of the snapshot caused the delta VMDK to be merged back into the source VMDK. This was especially impactful if the delta file was large–the data had to be reconsolidated back to the source while still servicing reads/writes. This caused this process to sometimes take hours. With VVols, there is no performance impact, the VM is always running off of the source data VVol, so when snapshots are created reads/writes never are redirected–the array just uses its snapshotting technology to maintain a tracker of what changed (in the FlashArray case the snapshot just stores the metadata  point-in-time of the source). Therefore, the creation of the snapshot is non-impactful because I/O is not redirected. Also the existence of a snapshot now is non-impactful because there is no complex redirection of I/O. And the deletion is non-impactful because the array just deletes the snapshots–there is no need to reconsolidate the changes back into the source. The snapshots store the old data, not the new data–the opposite of what traditional software-based VMware snapshots did.
• Restore time–to copy from them or to restore from them is instant–on the FlashArray it is just a meta data copy. So even if it is very large virtual disk the time to refresh or restore is the same.
• Efficiency–since everything on the FlashArray is globally deduped and compressed the snapshots that are created a very space efficient.
• Flexibility–this is an important one. While you should not delete managed snapshots on the array, instead you should use VMware to delete them–that does not mean you cannot do other things with them. I will explain what I mean by this in a blog post later in this series.

Below is a quick demo of what I did above plus an example of the flexibility bullet I mentioned just above and will expand on later in this blog series.