vVols User Guide: Snapshots of vVols
Snapshots of vVols
An important benefit of vSphere Virtual Volumes (vVols) is in its handling of snapshots. With VMFS-based storage, ESXi takes VM snapshots by creating a delta VMDK file for each of the VM’s virtual disks. It redirects new virtual disk writes to the delta VMDKs, and directs reads of unmodified blocks to the originals, and reads of modified blocks to the delta VMDKs. The technique works, but it introduces I/O latency that can profoundly affect application performance. Additional snapshots intensify the latency increase.
The performance impact is so pronounced that both VMware and storage vendors recommend the briefest possible snapshot retention periods - see Best practices for using snapshots in the vSphere environment (1025279) kb article. Practically speaking, this limits snapshot uses to:
Patches and upgrades
Taking a snapshot prior to patching or upgrading an application or guest operating system, and deleting it immediately after the update succeeds.
Backup
Quiescing a VM and taking a snapshot prior to a VADP-based VM backup. Again, the recommended practice is deleting the snapshot immediately after the backup completes.
These snapshots are typically of limited utility for other purposes, such as development testing. Adapting them for such purposes usually entails custom scripting and/or lengthy copy operations with heavy impact on production performance. In summary, conventional VMware snapshots solve some problems, but with significant limitations.
Array-based snapshots are generally preferable, particularly for their lower performance impact. FlashArray snapshots are created instantaneously, have negligible performance impact, and initially occupy no space. They can be scheduled or taken on demand, and replicated to remote arrays. Scripts and orchestration tools can use them to quickly bring up or refresh development testing environments.
Because FlashArray snapshots have negligible performance impact, they can be retained for longer periods. In addition, they can be copied to create new volumes for development testing and analytics, either by other VMs or by physical servers.
FlashArray administrators can take snapshots of VMFS volumes directly, however there are limitations:
No integration with ESXi or vCenter
Plugins can enable VMFS snapshot creation and management from the Web Client, but vCenter and ESXi have no awareness of or capability for managing them.
Coarse granularity
Array-based snapshots of VMFS volumes capture the entire VMFS. They may include hundreds or thousands of VMs and their VMDKs. Restoring individual VMDKs requires extensive scripting.
vVols eliminate both limitations. VMware does not create vVol snapshots itself; vSphere directs the array to create a snapshot for each of a VM’s data vVols. VASA then translates vSphere commands into FlashArray operations. VMware administrators use the same tools to create, restore, and delete VMFS and vVol snapshots, but with vVols, they can operate on individual VMDKs.
With Purity//FA when taking a managed snapshot the array will copy the VMs current data volume/s to new data volume/s that has a 'snap' suffix for it. Keep this in mind from an object count perspective. Then when creating a managed snapshot there will be an additional array volume created for each virtual disk.
Taking Managed Snapshots of vVol-based VMs
While the FlashArray GUI, REST, and CLI interfaces can be used for both per-VM and per-virtual disk vVol operations, a major advantage of vVols is management of vVols from within vCenter. VMware administrators can use the Web Client or any other VMware management tool to create array-based snapshots of vVol-based VMs.
To take a snapshot of a vVol-based VM with the Web Client, right-click the VM in the inventory pane, select Snapshots from the dropdown menu, and Take Snapshot from the secondary dropdown to launch the Take VM Snapshot for vVol-VM wizard. With vSphere 7.0 and higher in the HTML client Manage Snapshots has it's own tab again on the VM View. Snapshots can be managed, taken, reverted and deleted from this view.
![]() vSphere Client View - Right Clicking a VM to Take a Snapshot |
![]() vSphere Client View - Snapshot Management View |
![]() vSphere Client View - Managed Snapshot Wizard |
Enter a name for the snapshot, a description (optional) and optionally check one of the boxes:
Snapshot the virtual machine’s memory:
Causes the snapshot to capture the VM’s memory state and power setting. Memory snapshots take longer to complete, and may cause a slowdown in VM response over the network.
Quiesce guest file system:
VMware Tools quiesces the VM’s file system before taking the snapshot. This allows outstanding I/O requests to complete, but queues new ones for execution after restart. When a VM restored from this type of snapshot restarts, any queued I/O requests complete. To use this option, VMware Tools must be installed in the VM. Either of these options can be used with vVol-based VMs.
VMware administrators can also take snapshots of vVol-based VMs with PowerCLI, for example:
New-Snapshot -Name NewSnapshot -Quiesce:$false -VM vVolVM -Memory:$false
![]() vSphere Client View - vVols based VM's New Files |
When a snapshot of a vVol-based VM is taken, new files appear in the VM’s vVol datastore folder.
The files are:
VMDK (MSSQL-VM-01-000001.vmdk)
A pointer file to a FlashArray volume for the managed snapshot. If the VM is running from that VMDK, the file points to the data vVol that will have the active bind. If the VM is not running from that snapshot VMDK, the file points to a data vVol that is not bound. As administrators change VMs’ running states, VMware automatically re-points VMDK files.
Database file (MSSQL-VM-01.vmsd)
The VMware Snapshot Manager’s primary source of information. Contains entries that define relationships between snapshots and the disks from which they are created.
Memory snapshot file (MSSQL-VM-01-Snapshot7.vmsn)
Contains the state of the VM’s memory. Makes it possible to revert directly to a powered-on VM state. (With non-memory snapshots, VMs revert to turned off states.) Created even if the Snapshot the virtual machine’s memory option is not selected.
Memory file (not shown)
A pointer file to a memory vVol. Created only for snapshots that include VM memory states.
Creating a Managed Snapshot Without Saving Memory
If neither Snapshot the virtual machine’s memory nor Quiesce guest file system is selected, VMware directs the array to create snapshots with no pre-work. All FlashArray snapshots are crash consistent, so snapshots of vVol based-VMs that they host are likewise at least crash consistent.
The managed snapshot process for vVols comes in two parts: Prepare to Snapshot Virtual Volume (prepareToSnapshotVirtualVolume) and then Snapshot Virtual Volume (snapshotVirtualVolume). When a vSphere user initiates a managed snapshot operation vSphere will communicate with the array's VASA Provider to in the following method:
- vSphere issues a Prepare to Snapshot Virtual Volume request to the VASA Provider
- The VASA Provider ensures that the virtual volume is ready to have a managed snapshot taken
- On the FlashArray this is the step that the volumes are created with the data-vvol name with a -snap suffix
- If the VM has a policy and replication group associated with it, the data-snap volumes are placed in the protection group associated with that policy and replication group
- The VASA Provider responds back to vSphere that the prepare operation has completed and provides a uuid for the snapshot
- vSphere pauses the VM to ensure that no outstanding activity happens (Usually referred to as VM Stun time)
- vSphere issues a Snapshot Virtual Volume request to the VASA Provider for each Data vVol that the VM has
- The VASA provider copies out the data vVols to the managed snapshot
- On the FlashArray a purevol copy is issued where the data-vvol is copied out and overwrites the data-vvol-snap that was created during the prepare phase
- In vSphere 7.0 U3 and higher the Snapshot Virtual Volume request passes multiple vVol uuids as part of the request, which helps improve batching and performance at scale
- The VASA provider responds back to vSphere that Snapshot Virtual Volume is complete
- vSphere unpauses the VM (the VM is unstunned) and the managed snapshot operation is complete
While this seems like a lot of steps and process at first, they typically will complete under a ms. The biggest goal that both VMware and Pure Storage has is to decrease the amount of calls and time it takes between when the VM is stunned, snapshot virtual volume is issued and then completed.
Here is a view from the Snapshot Management for a normal snapshot that had completed.
![]() vSphere Client View - Snapshot Management View - Normal Snapshot |
Here is a view from the FlashArray that shows the new volume objects created for a managed snapshot.
![]() FlashArray GUI View - Managed Snapshot for vVols based VM |
Note:
FlashArray volume names are auto-generated, but VMware tools list the snapshot name supplied by the VMware administrator.
Creating a Managed Snapshot with Saved Memory
If the VMware administrator selects Store the Virtual Machine’s Memory State, the underlying snapshot process is more complex.Memory snapshots generally take somewhat longer than non-memory ones because the ESXi host directs the array to create a memory vVol to which it writes the VM’s entire memory image. Creation time is proportional to the VM’s memory size.
![]() vSphere Client View - Managed Snapshot Wizard |
Normal Snapshots, Memory Snapshots and File Quiesced Snapshots will all cause a VM to pause briefly. A normal snapshot causing the smallest amount of "VM Stun" during the snapshot process. File Quiesced and Memory based snapshots can have a VM "Stun Time" that varies depending on how busy the VM is, how large the VM is sized (Memory or Storage) and the version of vSphere. Typically the stun time for a VM snapshot will be seconds, but a memory snapshot could vastly increase the amount of stun time if the VM is sized large and is very busy.
The memory vVol in a VM’s volume group created as a consequence of a memory snapshot stores the VM’s active state (memory image). ArrayView 25 shows the volume group of a VM with a memory snapshot (vvol-test-a-VM-light-0011-92ecaac2-vg/Memory-f60d917b). The size of the memory vVol is the memory size of the VM’s memory image.
![]() FlashArray GUI View - Memory Managed Snapshot Object |
VMware flags a memory snapshot with a green play icon to indicate that it includes the VM’s memory state.
![]() vSphere Client View - Snapshot Management View - Memory Managed Snapshot |
Reverting a VM to a Managed Snapshot
VMware management tools can revert VMs to snapshots taken by VMware. As with snapshot creation, reverting is identical for conventional and vVol-based VM snapshots.
To restore a VM from a snapshot, from the Web Client Hosts & Clusters or VMs and Templates view, select the VM to be restored and click the Snapshots tab in the adjacent pane to display a list of the VM’s snapshots.
Select the snapshot from which to revert, click the All Actions button, and select Revert to from the dropdown menu.
![]() vSphere Client View - Reverting a VM to a Managed Snapshot |
Subsequent steps differ slightly for non-memory and memory snapshots.
Reverting a VM from a Non-memory Managed Snapshot
The Revert to command displays a confirmation dialog. Click Yes to revert the VM to the selected snapshot.
The array overwrites the VM’s data vVols from their snapshots. Any data vVols added to the VM after the snapshot was taken are unchanged.
Before reverting a VM from a non-memory snapshot, VMware shuts the VM down. Thus, reverted VMs are initially powered off.
Reverting a VM from Memory Managed Snapshot
To revert a VM to a memory snapshot, the ESXi host first directs the array to restore the VM’s data vVols from their snapshots, and then binds the VM’s memory vVol and reloads its memory. Reverting a VM to a memory snapshot takes slightly longer and results in a burst of read activity on the array.
A VM reverted to a memory snapshot can be reverted either suspended or to a running state. Check the Suspend this virtual machine when reverting to selected snapshot box in the Confirm Revert to Snapshot wizard to force the reverted VM to be powered off initially. If the box is not checked, the VM is reverted into its state at the time of the snapshot.
![]() FlashArray GUI View - Memory Snapshot Read IO |
Deleting a Managed Snapshot
Snapshots created with VMware management tools can be deleted with those same tools. VMware administrators can only delete snapshots taken with VMware tools.
To delete a VM snapshot from the Web Client Host and Clusters or VMs and Templates view, select the target VM and click the Snapshots tab in the adjacent pane to display a list of its snapshots.
Select the snapshot to be deleted, click the All Actions button, and select Delete Snapshot from the dropdown menu to launch the Confirm Delete wizard. Click Yes to confirm the deletion.
![]() |
VMware removes the VM’s snapshot files from the vVol datastore and directs the array to destroy the snapshot. Depending on whether FlashArray Safemode is enabled or not will have differing outcomes on the array.
When Safemode is disabled the VASA Provider will destroy and automatically eradicate the deleted managed snapshot. This helps reduce object count churn in environments that leverage managed snapshots as part of backup workflows.
One of the options when Safemode is enabled is disabling the manual eradication on the array. This means that the VASA Provider is no longer able to automatically eradicate the deleted managed snapshot. Keep this in mind when planning object count headroom when using vVols with FlashArray Safemode.
![]() FlashArray GUI View - Deleted Managed Snapshot objects are eradicated |
![]() FlashArray GUI View - Safemode is enabled - Deleted Managed Snapshot objects are not eradicated |
When VMware deletes a conventional VM snapshot, it reconsolidates (overwrites the VM’s original VMDKs with the data from the delta VMDKs). Depending on the amount of data changed after the snapshot, this can take a long time and have significant performance impact. With FlashArray based snapshots of vVols, however, there is no reconsolidation. Destroying a Flasharray snapshot is essentially instantaneous. Any storage reclamation occurs after the fact during the normal course of the array’s periodic background garbage collection (GC).
Unmanaged Snapshots - FlashArray Snapshots
Snapshots created with VMware tools are called managed snapshots. Snapshots created by external means, such the FlashArray GUI, CLI, and REST interfaces and protection group policies, are referred to as unmanaged. The only difference between the two is that VMware tools can be used with managed snapshots, whereas unmanaged ones must be managed with external tools.
Unmanaged snapshots (and volumes) can be used in the VMware environment. For example, FlashArray tools can copy an unmanaged source snapshot or volume to a target data vVol, overwriting the latter’s contents, but with some restrictions:
Volume size
A source snapshot or volume must be of the same size as the target data vVol. FlashArrays can copy snapshots and volumes of different sizes (the target resizes to match the source), but VMware cannot accommodate external vVol size changes. To overwrite a data vVol with a snapshot or volume of a different size, use VMware tools to resize the target vVol prior to copying.
Offline copying
Overwriting a data vVol while it is in use typically causes the application to fail or produce incorrect results. A vVol should be offline to its VM, or the VM should be powered off before overwriting.
Config vVols
Config vVols should only be overwritten with their own snapshots.
Memory vVols
Memory vVols should never be overwritten. There is no reason to overwrite them, and doing so renders them unusable.