Skip to main content
Pure Technical Services

vVols User Guide: Snapshots of vVols

Currently viewing public documentation. Please login to access the full scope of documentation.

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.

vVols Implementation Guide - Snapshots - 01.png
vSphere Client View - Right Clicking a VM to Take a Snapshot
vVols Implementation Guide - Snapshots - 02.png
vSphere Client View - Snapshot Management View 
vVols Implementation Guide - Snapshots - 03.png
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 
vVols Implementation Guide - Snapshots - 05.png
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:

  1. vSphere issues a Prepare to Snapshot Virtual Volume request to the VASA Provider
  2. The VASA Provider ensures that the virtual volume is ready to have a managed snapshot taken
    1. On the FlashArray this is the step that the volumes are created with the data-vvol name with a -snap suffix
    2. 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
  3. The VASA Provider responds back to vSphere that the prepare operation has completed and provides a uuid for the snapshot
  4. vSphere pauses the VM to ensure that no outstanding activity happens (Usually referred to as VM Stun time)
  5. vSphere issues a Snapshot Virtual Volume request to the VASA Provider for each Data vVol that the VM has
  6. The VASA provider copies out the data vVols to the managed snapshot
    1. 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
    2. 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
  7. The VASA provider responds back to vSphere that Snapshot Virtual Volume is complete
  8. 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.

vVols Implementation Guide - Snapshots - 04.png
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.

vVols Implementation Guide - Snapshots - 06.png
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.

vVols Implementation Guide - Snapshots - 07.png
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.

vVols Implementation Guide - Snapshots - 09.png
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.

vVols Implementation Guide - Snapshots - 08.png
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.

vVols Implementation Guide - Snapshots - 10 - 1.png
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.

vVols Implementation Guide - Snapshots - 11.png
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.

vVols Implementation Guide - Snapshots - 12.png

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.

vVols Implementation Guide - Snapshots - 13.png
FlashArray GUI View - Deleted Managed Snapshot objects are eradicated
vVols Implementation Guide - Snapshots - 14.png
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.

Snapshot Management with the Plugin

Viewing VM vVol details

When a FlashArray is registered with the vSphere Plugin there will be details reported in vCenter for vVols based Virtual Machines that are stored on that FlashArray.  These details are explained here in the Demo Video.  Click to expand the explanation below.

Viewing the Virtual Machine vVol Details with the Pure Storage vSphere Plugin
  1. From the Virtual Machine view and Summary Tab, there is a FlashArray widget box.  This will show whether or not the VM has Undelete Protection.  Undelete Protection means that there is currently a FlashArray Snapshot of this VMs Config vVol.
    vvols-plugin-kb-04-VM-Details-1.png
  2. On the Virtual Machine's Configure Page, there is a Pure Storage Virtual Volumes tab.  
    vvols-plugin-kb-04-VM-Details-2.png

    The page will allow end users to run the workflows to Import a virtual disk (vVol), restore a destroyed vVol or to Overwrite an existing vVol.
    Additionally the page contains important information about the VMs Data vVols.  Some of the important information here would be the Virtual Device (SCSI controller connection), the vVol Datastore that the vVol is on, which Array the vVol is on and the FlashArray Volume Group Name and Volume name.

Creating a FlashArray Snapshot of a vVol Disk 

The Pure Storage Plugin version 4.4.0 and later for the vSphere Client has the ability to create a new snapshot of only a vVol virtual disk.

Create a Snapshot of a vVol Disk
  1. From the Virtual Machine Configure tab, navigate to the Pure Storage - Virtual Volumes pane, select the disk you would like to snapshot and click Create Snapshot.

     

     

    clipboard_ee1b1a9dde32840f3374ab7d72fcfc010.png

  2. After clicking the Create Snapshot button, a dialog appears. You can optionally enter a snapshot name, otherwise it will assign the next available numerical name for the snapshot. Click Create.

     

    clipboard_ead9911a2a356f2ae181f303ec96b1e4f.png

  3. After the workflow is complete, you can verify the snapshot by either clicking the Import Disk or the Overwrite Disk button and finding the correct disk and expanding its snapshots.

    clipboard_ee7ee1501092792ea27f6dda452961b65.png

 

Restoring a vVol from a FlashArray Snapshot

The Pure Storage vSphere plugin has the ability to recover a destroyed vVol within 24 hours of when the vVol was destroyed.  There is also an integration to overwrite an existing vVol with a previous FlashArray snapshot of the vVol.  These workflows are covered in the Demo Video here.  Click to expand the workflows below.

Restoring a Destroyed vVol with the Pure Storage vSphere Plugin
  1. From the Virtual Machines Configure page, navigate to the Pure Storage - Virtual Volumes tab, select Restore Deleted Disk.

    When deleting a Data vVol, the FlashArray will destroy the volume and the volume will be in a Pending Eradication state for 24 hours.

    In this workflow example, the VM 405-Win-VM-2 has had the virtual disk "Hard disk 2" deleted from disk.  
    vvols-plugin-kb-05-Restoring-vvol-1.png
  2. After selecting the Restory Deleted Disk option, any Data vVols that have been destroyed and are pending eradication will be displayed.  Select the Data vVol that should be restored and click Restore to complete the workflow.
    vvols-plugin-kb-05-Restoring-vvol-2.png
  3. After the workflow is complete, the recovered vVol will be displayed in the Pure Storage Virtual Volumes tab.
    vvols-plugin-kb-05-Restoring-vvol-3.png
Rolling Back a vVol with the Pure Storage vSphere Plugin
  1. From the Virtual Machines Configure page, navigate to the Pure Storage - Virtual Volumes tab, select Overwrite Disk.
    vvols-plugin-kb-05-Restoring-vvol-4.png
  2. From this page, select the vVol based VM and the Data vVol from that VM that you want to use to overwrite the Data vVol with.  While this can be a different vVol VM or the same vVol VM that you want to import the data vVol to, the example show will be to roll back this Data vVol to a previous snapshot.  Here Hard Disk 2 is selected and when expanded all Snapshots for that vVol are shown.  In this case, the one selected in a Snapshot from the FlashArray pgroup "vSphere-Plugin-pgroup-2" and the Snapshot Name of "Safe-Snapshot".
    vvols-plugin-kb-05-Restoring-vvol-5.png
    In the Volume Information for the selected snapshot, we can see when the snapshot was created and the information for this vVol that will be used to Overwrite the Existing Data vVol.
    Click on Overwrite to complete the workflow. 

Creating a vVol Copy 

With the Pure Storage vSphere plugin there is the ability to import a vVol from the same vVol VM or from another vVol VM.  The source can be either a FlashArray Snapshot or a Managed Snapshot.  The workflows for importing the same vVol from either a FA Snapshot or a Managed Snapshot is walked through below as well as in the Demo Video here.

Creating the Copy from a FlashArray Snapshot with the Pure Storage vSphere Plugin
  1. From the Virtual Machines Configure page, navigate to the Pure Storage - Virtual Volumes tab, select Import Disk.
    vvols-plugin-kb-06-vvol-copy-1.png
  2. From this page, select the vVol based VM and the Data vVol from that VM that you want to recover.  This can be a different vVol VM or the same vVol VM that you want to import the data vVol to.  In this example the Hard Disk 2 is selected and when expanded all Snapshots for that vVol are shown.  In this case, the one selected in a Snapshot from the FlashArray pgroup "vSphere-Plugin-pgroup-2" and the Snapshot Name of "53".
    vvols-plugin-kb-06-vvol-copy-2.png
    In the Volume Information for the selected snapshot, we can see when the snapshot was created and the information for this vVol that will be imported.
    Click on Import to complete the workflow. 
Creating the Copy from a Managed Snapshot with the Pure Storage vSphere Plugin
  1. From the Virtual Machines Configure page, navigate to the Pure Storage - Virtual Volumes tab, select Import Disk.
    vvols-plugin-kb-06-vvol-copy-1.png
  2. Instead of using a FlashArray pgroup snapshot to import the vVol, this time a Managed Snapshot will be selected.  Notice the difference in the naming for the selected vVol.  There is no pgroup or snapshot name associated with it.  Just the volume group and data vvol name, followed by a "-snap" indicating that this is a managed snapshot for this vVol.  
    vvols-plugin-kb-06-vvol-copy-3.png
    The same type of information is provided in the Volume Information for Managed Snapshot or FlashArray Snapshots.
    To complete the import workflow, click on Import.
     
  3. Once the Import Workflows have completed, the new Data vVols will show up on the Virtual Volumes page.
    vvols-plugin-kb-06-vvol-copy-4.png