Skip to main content
Pure Technical Services

Web Guide: vSphere Virtual Volume VM Recovery and Snapshot Workflows

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

KP_Ext_Announcement.png
Data Mobility and SPBM are a couple of the great features of Pure Storage's integration with vSphere Virtual Volumes (vVols), but what are some real examples and workflows that take advantage of these features?  This KB covers some real examples of importing a Data vVol from one VM to another, recovering a deleted vVol VM and recovering a deleted Data vVol.

Overview

The main purpose of this KB is to show some workflows and examples of VVol VM recovery related scenarios, like recovering a deleted vm with or without a backup of the config volume or creating a clone of a running VVol VM (but use the data volumes from a snapshot taken 10 days ago).  The goal is to provide real examples and workflows for events that the VMware Admin may need to use in high pressure situations.  

Before beginning let's review the setup and environment that will be used in the example workflows to follow.

>> Here is an Overview of the Environment and Virtual Machines used for the workflows in the KB (click to expand)
Here are 4 VVol VMs- two VMs per vCenter and each will have a different snapshot method.
Each VM is a Windows Server 2016 VM with a 200 GB VMDK and 40 GB VMDK.  The 200 GB is the OS volume and the 40 GB is the E Drive:
VVol KB - 00 - VM Overview.png
 
VVol VM 1 will be using Managed snapshots:
VVol KB - 01 - VM-1 - Managed Snapshot 01.png

The option to snapshot memory or quiesce the file system are not checked:
VVol KB - 01 - VM-1 - Managed Snapshot 02.png

Now, looking at the FlashArray for this VVol VM, the two Data Volumes have an additional volume with a -snap suffix:
VVol KB - 01 - VM-1 - Managed Snapshot 03.png

However, that is just for the Data Volumes.  Take note that there is no snapshot or copy of the Config Volume:
VVol KB - 01 - VM-1 - Managed Snapshot 04.png

This is a key difference between storage policies and manual protection group snapshots.  Without a backup of the Config volume, recovering a VM that was deleted or recovering a deleted VMDK gets a little bit more tricky.  More on that to come.
On to VVol VM 2.  Here a Storage Policy with Replication will be applied:
VVol KB - 02 - VM-2 - Storage Policy 01 .png

Here the storage policy "1 hour replication" is applied to the VM Home (config volume) and the two VMDKs (data volumes):
VVol KB - 02 - VM-2 - Storage Policy 02.png

There is a specific replication group (flasharray protection group) that is selected for all volumes:
VVol KB - 02 - VM-2 - Storage Policy 03.png

The policy has been applied and is compliant:
VVol KB - 02 - VM-2 - Storage Policy 04.png

Looking at the FlashArray for VVol VM 2, notice that there are not any -snap volume copies and there are no volume snapshots found:
VVol KB - 02 - VM-2 - Storage Policy 05.png

However, look at the individual volumes (Config and Data) and you will see that the volume is part of a Protection Group as expected:
VVol KB - 02 - VM-2 - Storage Policy 06.png

The key part here is that we have a backup of the Config Volume.  This is important as we have a point at which we can recover a deleted VM or VMDK in some cases.

Here is VVol-VM-3, which is much like VVol-VM-2 except it's a local snapshot storage policy and not a replication policy.  The setup and configuration is similar to VVol-VM-2, just a different policy and replication group:
VVol KB - 03 - VM-3 - Storage Policy 01.png

Again, very similar to VVol-VM-2, no volume snapshot for the VVol VM:
VVol KB - 03 - VM-3 - Storage Policy 02.png

And here we see that the Config Volume is part of a protection group and there is a snapshot of the Config Volume:
VVol KB - 03 - VM-3 - Storage Policy 03.png

With VVol-VM-4 we will be doing some manual snapshots (using the Pure web client plugin):
VVol KB - 04 - VM-4 - Manual Snapshot 01.png

We will take a manual snapshot of both the boot volume and the second vmdk:
VVol KB - 04 - VM-4 - Manual Snapshot 02.png

On the FlashArray we can see that there are snapshots for both Data volumes:
VVol KB - 04 - VM-4 - Manual Snapshot 03.png

However, there are no snapshots for the Config Volume:
VVol KB - 04 - VM-4 - Manual Snapshot 04.png

So VVol-VM-4 and VVol-VM-1 both have a "backup" of the two data volumes, but there is no backup of the config volume in either.

Let's review the FlashArray Protection Groups and see what they look like.  

With VVol-pgroup-rep-1 we see that VVol-VM-2 has the Config and both Data Volumes as members.  This is expected as this VM had the storage policy for this pgroup applied:
VVol KB - 05 - vvol-pgroup-rep-1 - overview.png

Then looking at the VVol-pgroup-snap-1 Protection Group we see that VVol-VM-3 has the Config and both Data Volumes as members as well:
VVol KB - 06 - vvol-pgroup-snap-1 - overview.png

In addition to the two pgroups above, I created a manual snapshot pgroup that does not have a snapshot or replication schedule.  Only the two Data Volumes for VVol-VM-4 were added as well as a manual snapshot for this pgroup:
VVol KB - 04 - VM-4 - Manual Snapshot 05.png

Let's take a look at the VVol VMs and files that are there.

With VVol-VM-1 there is the E drive labeled as VM-1-Volume and there are three files of varying sizes in that volume:
VVol KB - 07 - VM 1 - Vol and Files.png

With VVol-VM-2 there is the E drive labeled as VM-2-Volume and there are three files that are the same size:
VVol KB - 07 - VM 2 - Vol and Files.png

With VVol-VM-3 there is the E drive labeled as VM-3-Volume and there are three files that are the same size:
VVol KB - 07 - VM 3 - Vol and Files.png

With VVol-VM-4 there is the E drive labeled as VM-4-Volume and there are three files that are the same size:
VVol KB - 07 - VM 4 - Vol and Files.png

Now that we have a view what VVol VMs and what everything looks like on the array we can start to look at some of these scenarios.


Workflows

Here are the main workflows that will be demonstrated:

  1. Recovering a Deleted VVol VM within 24 Hours
  2. Recovering a Deleted VVol VM after 24 Hours
  3. Recovering a Deleted VVol VM VMDK within 24 Hours
  4. Recovering a Deleted VVol VM VMDK after 24 Hours
  5. Cloning a VVol VM from a point in time snapshot
  6. Importing a Virtual Volume into another VM

With each of these situations we'll see a workflow where the VM has a storage policy applied that is replicating or has local snapshots, if there are Managed Snapshots for the VM, if the VM is manually put into a FlashArray protection group, if the VM has manual snapshots and finally if there are no snapshots. 

>> The process of deleting each of the VMs was powering them off and then deleting from disk as follows: (click to expand)

Here the VM will be first powered off:

VVol KB - 08 - VM 1 - 01 - Power Off.png

After the VM is powered off, it is then deleted from disk:

VVol KB - 08 - VM 1 - 02 - Delete from Disk.png

This same process is used for each of the VMs:

VVol KB - 08 - VM 2 - 01 - Power Off.png

After the VM is powered off, it is then deleted from disk:

VVol KB - 08 - VM 2 - 02 - Delete from Disk.png

Then, from the FlashArray, we can see the Volume Groups and Volumes pending eradication:

VVol KB - 09 - FlashArray - 01 - Destroyed vgroup and vols.png

Let's get started.


Recovering a Deleted VVol VM within 24 Hours

In this example, a VVol VM will be deleted in vCenter.  The workflow will be recovering the VM within 24 hours.  The point here is that when a VVol VM is deleted in vCenter, the FlashArray Volume Group and Volumes are destroyed but not eradicated.  After 24 hours the volumes and volume group will be eradicated.  With each of these workflows the Volume Group and Volumes will need to be recovered.

>> Here is the Workflow followed to recover the FlashArray Volume Groups and Volumes: (click to expand)

Recover the Volume Groups:

VVol KB - 09 - FlashArray - 02 - vgroup recovery.png
VVol KB - 09 - FlashArray - 03 - vgroup recovery.png

Once the Volume Groups are Recovered, then recover their Volumes.  There are a couple of ways to do this.  One is to recover the volumes from the volume overview page.

With this example, VVol-VM-2's volumes will be recovered:

VVol KB - 09 - FlashArray - 04 - vgroup recovery.png

Select VVol-VM-2's Volumes and then Recover:

VVol KB - 09 - FlashArray - 05 - volume recovery.png

Once Recovered, the Volume Group for VVol-VM-2 will show the Config and two Data volumes as part of that Volume Group:

VVol KB - 09 - FlashArray - 06 - vm-2 vgroup and vols.png

Another way to recover the Volumes would be to navigate to the Recovered Volume Group directly, in this example VVol-VM-1.

Then expand the Destroyed Volumes, click on the options and then select Recover:

VVol KB - 09 - FlashArray - 07 - vm-1 vgroup and vols.png

Select all of the volumes and then recover:

VVol KB - 09 - FlashArray - 08 - vm-1 vgroup and vols.png

Now the Volume Group will show that each of the destroyed Volumes are recovered:

VVol KB - 09 - FlashArray - 09 - vm-1 vgroup and vols.png

This process was followed for the remaining VMs VVol-VM-3 and VVol-VM-4.

Now when browsing the VVol Datastore in vCenter, you will see that the VM Directories are there; however, they are empty since the Config Volume was cleaned up before the FlashArray was requested to destroy the Config Volume:

VVol KB - 10 - vCenter VVol Datastore Files.png

Now that the Volume Groups and Volumes have been recovered, let's walkthrough how to recover the VMs that were deleted in vCenter.

With vCenter Storage Policies (SPBM)

When using the Storage Policies, the Config and Data Volumes are added to the FlashArray protection group.  This means that we have a backup of the Config Volume.

After the volume group and volumes have been recovered, the next step will be to navigate to the Config Volume and then recover the Config Volume from the snapshot that was taken before the VM was deleted.

There were two VMs with Storage Policies applied to them; this example will be using VVol-VM-3 as the recovery example.  The volume group has already been recovered since it has the volumes currently.  The next step is to recover the Config Volume and then register the recovered VM.

>> Here is the Workflow followed to recover the Config Volume and Register the Recovered VM: (click to expand)

Navigate to the Volume Group page:

VVol KB - 11 - vm-3 recovery - 01 - FlashArray vgroup.png

Then Select the Config VVol:

VVol KB - 11 - vm-3 recovery - 02 - FlashArray config volume.png

Over in the Volume Snapshots for the snapshot you are restoring from (basically the one before the VM was destroyed), click the options button and then select Restore:

VVol KB - 11 - vm-3 recovery - 03 - FlashArray config restore.png

Keep in mind that doing the restore option here will overwrite the existing volume.  The goal here is to restore the Config Volume to the point in time before the VM was deleted.  Click on Restore then navigate back to vCenter:

VVol KB - 11 - vm-3 recovery - 04 - vCenter Datastore Browse.png

Once in vCenter, navigate to the VVol Datastore, then Files and then to the VM that is being recovered; if you are already on that page, refresh the page.  Now you will see all of the correlating files for that VM.  Select the VMX file and then register the VM:

VVol KB - 11 - vm-3 recovery - 05 - Register VM 0.png

After the VM is registered, navigate to the VM page, select the recovered VM and then Power the VM on:

VVol KB - 11 - vm-3 recovery - 06 - Power On VM 1.png

Before the VM is powered on, there will be a question asked if the VM was moved or copied.  Answer the question that the VM was copied:

VVol KB - 11 - vm-3 recovery - 06 - Power On VM 3.png

When the VM is powered on check that the files, application, etc all look good and the VM is accessible.  In this example we can see all the VVol-VM-3 files are in place with the E drive:

VVol KB - 11 - vm-3 recovery - 07 - Check VM 3 Files.png

There it is, when using SPBM with the VVol VMs recovering the deleted VM is a straightforward process as there is a backup of the Config Volume that can be recovered.

With vCenter Managed Snapshots

Sadly, with vCenter Managed Snapshots there is no snapshot taken of the Config Volume.  This means we will need to create a new VVol VM (it can be empty) to get the correct mappings in place to then copy out the Data Volumes and then power on the recovered VM.

>> Here is the Workflow followed to create a new VVol VM: (click to expand)

From vCenter select the New Virtual Machine option

VVol KB - 12 - vm-1 recovery - 01 - vCenter New VM 01.png

Create a new Virtual Machine:

VVol KB - 12 - vm-1 recovery - 01 - vCenter New VM 02.png

Give it the name of the deleted VM and the location for the VM:

VVol KB - 12 - vm-1 recovery - 01 - vCenter New VM 03.png

Choose the Compute Resource (match with what it was previously):

VVol KB - 12 - vm-1 recovery - 01 - vCenter New VM 04.png

Select a storage policy and the VVol Datastore that the deleted VM was on:

VVol KB - 12 - vm-1 recovery - 01 - vCenter New VM 05.png

Make sure the CPU and Memory are the same as what the VM had previously.
Then, match the Hard Disks size with what the size of the VMDKs were on the VM that was deleted.  In this case, the C Drive is 200 GB and the E Drive was 40 GB:

VVol KB - 12 - vm-1 recovery - 01 - vCenter New VM 06.png

Review all the information, make sure it looks right and then finish:

 

VVol KB - 12 - vm-1 recovery - 01 - vCenter New VM 07.png

 Now that there is a new VVol VM, on the FlashArray, there will be a new VVol-VM-1 Volume Group and associated Data Volumes that we will use as the copy out target.

>> Here is the Workflow followed to copy out the recovered volumes and overwrite the new VM's volumes: (click to expand)

From the FlashArray, we can see the new VM's Volume Group as well as the recovered Volume Group:

VVol KB - 12 - vm-1 recovery - 02 - FlashArray Volumes Overview .png

Then from the new VM's Volume Group, note the name of VMDK 1 and VMDK 2 Data Volumes (copy them down somewhere):

VVol KB - 12 - vm-1 recovery - 03 - FlashArray New vgroup.png

From the recovered Volume Group identify the Data Volumes for VMDK 1 and VMDK 2:

VVol KB - 12 - vm-1 recovery - 04 - FlashArray Old vgroup.png

To recover VMDK 1, click on the volume for VMDK 1, confirm it's the correct size and volume name, then click on options and select copy:

VVol KB - 12 - vm-1 recovery - 05 - FlashArray Copy Data Vol 1 - 01.png

Make sure that the Volume Group selected in the new Volume Group, for the volume name put in the exact name of the recovery data volume and select the overwrite option:

VVol KB - 12 - vm-1 recovery - 05 - FlashArray Copy Data Vol 1 - 02.png

Again, confirm that the correct data volume is getting overwritten then proceed:

VVol KB - 12 - vm-1 recovery - 05 - FlashArray Copy Data Vol 1 - 03.png

Then proceed to do the same thing for the Data volume for VMDK 2:

VVol KB - 12 - vm-1 recovery - 06 - FlashArray Copy Data Vol 2 - 01.png

Confirm that the correct Volume Group and Data Volume name are being used:

VVol KB - 12 - vm-1 recovery - 06 - FlashArray Copy Data Vol 2 - 02.png
VVol KB - 12 - vm-1 recovery - 06 - FlashArray Copy Data Vol 2 - 03.png

Navigate to the New Volume Group and notice that the two Data volumes have an updated source volume:

VVol KB - 12 - vm-1 recovery - 07 - FlashArray new vgroup updated.png

Back in vCenter, select the VM that was created and power it on, VVol-VM-1 is used in this example:

VVol KB - 12 - vm-1 recovery - 08 - vCenter 01 - Power On VM.png

After the VM is powered on, log in and confirm that the application and files look good:

VVol KB - 12 - vm-1 recovery - 08 - vCenter 02 - Check VM Files.png

 There we have it, the above is the workflow for recovering a deleted VM from Managed Snapshots when there is no backup of the Config Volume.

With Array Protection Groups

The following example would be if SPBM was not in use, but the VM's volumes were manually put into a FlashArray Protection Group.  The workflow will be similar to the one shown with SPBM in use if the Config Volume was in the protection group.  If only the Data Volumes were put into the protection group then the example with manual snapshots will be used.

>> If there is a backup of the Config Volume: (click to expand)

Follow the process outlined in the SPBM example.

  1. From the FlashArray, recover the Volume Group
  2. From the FlashArray, recover the Volumes in the recovered Volume Group
  3. From the FlashArray, navigate to the recovered Volume Groups Config Volume
  4. From the FlashArray, select the snapshot to recover the Config volume from and then recover the Config Volume
  5. From vCenter, refresh the VVol Datastore's files, then navigate to the Recovered VM
  6. From vCenter, register the Recovered VM's vmx file
  7. From vCenter, power on the Recovered VM and check that everything is running as expected
>> If there is no backup of the Config Volume: (click to expand)

Follow the Managed Snapshots Example.

  1. From the FlashArray, recover the Volume Group
  2. From the FlashArray, recover the Volumes in the recovered Volume Group
  3. From vCenter, create a new VVol VM with the same configuration (CPU, Memory and VMDKs) as the deleted VM
  4. From the FlashArray, navigate to the new Volume Group, get the Volume Name for each Data Volume
  5. From the FlashArray, navigate to the recovered Volume Group, select the Data Volume for VMDK 1
  6. From the FlashArray, copy the Data Volume for VMDK 1 to overwrite the Data Volume on the new Volume Group for VMDK 1
  7. Repeat for any additional VMDKs as needed
  8. From vCenter, select the new VM that was created and power on the VM
  9. Access the VM after it's powered on (RDP or Console) and confirm the Application or Files are all there

With Manual Snapshots

There are two types of workflows here.  First- if the the Config Volume has a manual snapshot.  Second- if only the Data Volumes have a manual snapshot.  If there is a snapshot of the Config Volume, then the workflow is the same as the one shown in the SPBM example.  If only the Data Volumes have manual snapshots, then the workflow will be similar to the managed snapshots workflow or if array protection groups were used on just the Data Volumes.

>> If there is a backup of the Config volume: (click to expand)

Follow the process outlined in the SPBM example.

  1. From the FlashArray, recover the Volume Group
  2. From the FlashArray, recover the Volumes in the recovered Volume Group
  3. From the FlashArray, navigate to the recovered Volume Groups Config Volume
  4. From the FlashArray, select the snapshot to recover the Config volume from and then recover the Config Volume
  5. From vCenter, refresh the VVol Datastore's files, then navigate to the Recovered VM
  6. From vCenter, register the Recovered VM's vmx file
  7. From vCenter, power on the Recovered VM and check that everything is running as expected
>> If there is no backup of the Config volume: (click to expand)

Follow the Managed Snapshots Example.

  1. From the FlashArray, recover the Volume Group
  2. From the FlashArray, recover the Volumes in the recovered Volume Group
  3. From vCenter, create a new VVol VM with the same configuration (CPU, Memory and VMDKs) as the deleted VM
  4. From the FlashArray, navigate to the new Volume Group, get the Volume Name for each Data Volume
  5. From the FlashArray, navigate to the recovered Volume Group, select the Data Volume for VMDK 1
  6. From the FlashArray, copy the Data Volume for VMDK 1 to overwrite the Data Volume on the new Volume Group for VMDK 1
  7. Repeat for any additional VMDKs as needed
  8. From vCenter, select the new VM that was created and power on the VM
  9. Access the VM after it's powered on (RDP or Console) and confirm the Application or Files are all there

No Snapshots?

If there are no snapshots, then we are still okay.  The process will actually be similar to how we would recover the manual snapshots and managed snapshots.  The main thing here is without a Config Volume backup, we'll need to "recreate" the VVol VM and then copy out the recovered FlashArray data volumes.

>> Here is the Workflow followed to recover a deleted VM with no snapshots: (click to expand)

Follow the Managed Snapshots Example to create a new VM and then to copy out the Data Volumes to overwrite the "new" volumes.

  1. From the FlashArray, recover the Volume Group
  2. From the FlashArray, recover the Volumes in the recovered Volume Group
  3. From vCenter, create a new VVol VM with the same configuration (CPU, Memory and VMDKs) as deleted VM
  4. From the FlashArray, navigate to the new Volume Group, get the Volume Name for each Data Volume
  5. From the FlashArray, navigate to the recovered Volume Group, select the Data Volume for VMDK 1
  6. From the FlashArray, copy the Data Volume for VMDK 1 to overwrite the Data Volume on the new Volume Group for VMDK 1
  7. Repeat for any additional VMDKs as needed
  8. From vCenter, select the new VM that was created and power on the VM
  9. Access the VM after it's powered on (RDP or Console) and confirm the Application or Files are all there

Recovering a Deleted VVol VM after 24 Hours

Now that we've reviewed how you can recover a VM that was deleted within that 24 hour window, how would you recover the deleted VM after 24 hours?  

Let's see how to recover the deleted VM with the same scenarios as outlined previously.  The difference here is that the volume groups and volumes have now been eradicated since the 24 hours has past.  

With vCenter Storage Policies (SPBM)

We have a VM that was using a Storage Policy that had local snapshots taken.  With those snapshots, we have the Data Volumes backed up.  This means we have Data Volumes that we can recover.  We will have to first create a new VM with the same amount of VMDKs with the same sizes and then overwrite the data volumes with the snapshots of the deleted VMs.

>> Here is the Workflow to recover a VVol VM from FlashArray snapshots: (click to expand)
  1. Create a new VM; this is covered earlier here.
  2. Identify the the new VMs Data volumes, here with VVol-VM-2, Data-440a997f is VMDK 1 and Data-b216fedd is VMDK 2:

    VVol KB - 13 - vm-2 recovery - 01 - FlashArray Find Data Volumes.png
  3. Identify the snapshots for the data volumes that will be used to overwrite the new data volumes. One way to do this is via the purecli:

    # purevol list --snap *VVol-VM-2-*
    Name                                                                             Size  Source                                                       Created                  SerialVVol-pgroup-snap-A.339.vvol-VVol-VM-2-d58d1a92-vg/Config-b5aa6153  4G    -       2019-05-06 10:41:00 PDT  1037B35FD0EF40A500093D96
    VVol-pgroup-snap-A.339.vvol-VVol-VM-2-d58d1a92-vg/Config-b5aa6153  4G    -       2019-05-06 10:41:00 PDT  1037B35FD0EF40A500093D96
    VVol-pgroup-snap-A.339.vvol-VVol-VM-2-d58d1a92-vg/Data-060d23c1    200G  -       2019-05-06 10:41:00 PDT  1037B35FD0EF40A500093D97
    VVol-pgroup-snap-A.339.vvol-VVol-VM-2-d58d1a92-vg/Data-b88a7c8b    40G   -       2019-05-06 10:41:00 PDT  1037B35FD0EF40A500093D98
    

    Here the snapshot for Data-060d23c1 is for VMDK 1 and the snapshot for Data-b88a7c8b is for VMDK 2.

  4. Copy out the snapshot volumes and overwrite the new data volumes.
    In this example Data-060d23c1 will overwrite Data-440a997f and Data-b88a7c8b will overwrite Data-b216fedd:
    VVol KB - 13 - vm-2 recovery - 02 - FlashArray Find Data Volumes.png
    VVol KB - 13 - vm-2 recovery - 03 - FlashArray Find Data Volumes.png
    VVol KB - 13 - vm-2 recovery - 04 - FlashArray Find Data Volumes.png VVol KB - 13 - vm-2 recovery - 05 - FlashArray Find Data Volumes.png
  5. Once the Copy operations are complete, navigate to vCenter, power on the VM and confirm the application/files are all in place.

With vCenter Managed Snapshots

As managed snapshots are destroyed when a VVol VM is deleted, they in turn will also be eradicated after the 24 hour period has passed.  Without array protection group snapshots or replicated snapshots the VM will be lost.  

With Array Protection Groups

As long as there are snapshots with the data volumes in them, then the VM can be recovered.  The same process outlined with the Storage Policies above will be the workflow to recover the VM.

With Manual Snapshots

If 24 hours have passed and should the manual snapshot have only been taken with the Pure vSphere Web Client Plugin or have manually been taken on the volume directly, then the manual snapshots have been eradicated as well.  In this case, lesson learned:  use SPBM with snapshot or replication schedules.

No Snapshots?

Unfortunately without any snapshots the VM is lost after the volume group and volumes have been eradicated.  Lesson to learn here, use SPBM with snapshot or replication schedules.


Recovering a Deleted VVol VM VMDK within 24 Hours

One of the awesome features of VVols is the ability to easily recover a destroyed VMDK within 24 hours without even needed snapshots or backups.  There are essentially going to be two ways to recover a deleted VMDK within 24 hours.  The first and easiest way will be with the Pure Storage vSphere Web Client Plugin.  The second and a little more work would be without the web client plugin.

With the Pure Storage Web Client Plugin

>> Here is the Workflow to recover a VVol VM VMDK with the plugin: (click to expand)

The Virtual Disk is deleted from vCenter when editing the VM's settings.

VVol KB - 14 - vm-2 recovery - 01.png

Now that virtual disk is deleted from the VM and on the FlashArray you can see that the data VVol is destroyed and will pend eradication for 24 hours.

VVol KB - 14 - vm-2 recovery - 02.png

To recover the virtual disk, navigate to the VM, click on FlashArray Virtual Volume Objects and then click on Restore Deleted Disk.

VVol KB - 14 - vm-2 recovery - 03.png

Then select the deleted disk and click restore.

VVol KB - 14 - vm-2 recovery - 04.png

Looking at the FlashArray, you'll see that the Volume has been recovered. 

VVol KB - 14 - vm-2 recovery - 05.png

Looking back at the VM's Virtual Volume Objects tab, you'll see that the Virtual Disk is restored.  You can log into the Guest OS and check that the volume is still all good with the Guest OS.

VVol KB - 14 - vm-2 recovery - 06.png

All done, easy and quick when you use the plugin! 

Without the Pure Storage Web Client Plugin

Use the plugin...seriously, just use the plugin.  If you can't, don't want to or won't use the plugin, then here is what you'd need to do.  

  1. In vCenter, create a new Virtual Disk that is the same size as the VMDK that you destroyed.
  2. On the FlashArray, recover the destroyed VMDK
  3. Overwrite the new VMDK - Data VVol - with the Data VVol that was just recovered.
  4. From the Guest OS, check that everything is recovered.
>> Click to expand and view the Workflow:
Here the destroyed volume is getting recovered and renamed.
VVol KB - 15 - VVol-VM-2-Recovery-01.gif
Now in vCenter create a new Virtual Disk that is the same size as the recovered Data VVol.
VVol KB - 15 - VVol-VM-2-Recovery-02.gif
Then copy out the recovered data VVol and overwrite the new data VVol.
VVol KB - 15 - VVol-VM-2-Recovery-03.gif

Now, this isn't to say that there are ways to recover this via PowerCLI or the vCenter API.  For the sake of this KB though, I won't go into that.  It would make for some good future blog posts though :) 


Recovering a Deleted VVol VM VMDK after 24 Hours

In the event that you have deleted a VVol VMDK and the destroyed data VVol is eradicated, there is still the workflow to recover that volume.  However, it's dependant on having some form of backup of that data volume.  Two factors here though, manual volume snapshots and managed snapshots of that data VVol will be eradicated along with the source VVol.  This means that you will need an Array based snapshot 

With vCenter Storage Policies (SPBM)

This one is straight forward and almost the exact same process covered in Recovering a Deleted VVol VM after 24 hours.  The difference being that you are only recovering a Data VVol and don't have to create a brand new VM.  Rather you just need to create a new virtual disk of the same size on the VVol VM, locate the volume snapshot, and then copy the snapshot out and overwrite the new VMDK.

Here are some gifs that cover the process of creating the new vmdk, overwriting the new data vvol with the snapshot volume and then refreshing the volume in the guest OS.

>> Click to expand and view the workflow:
First part is to create a new Virtual Disk for the VVol VM.  This will in turn create a new Data VVol on the FlashArray.  Make sure it's the same size as the Data VVol you are working to recover.
VVol KB - 15 - VVol-VM-2-Recovery-04.gif
Copy the name of the new Data VVol and then locate the snapshot that you want to recover from and then find the Data VVol and copy it out.
VVol KB - 15 - VVol-VM-2-Recovery-05.gif
Here I log into the VM and refresh the Disks.  Then the volume shows back up as mounted and everyone is happy.
VVol KB - 15 - VVol-VM-2-Recovery-06.gif

Overall, not too bad with array based snapshots.

With vCenter Managed Snapshots

An interesting part with managed snapshots, when you destroy a VVol VMDK, vCenter does not issue a destroy and eradicate request to the VASA provider for either the Data VVol or it's snapshot volume on the FlashArray.  So, in theory you should be able to destroy the FA objects and use the plugin to recover them or use them to copy out and overwrite a new empty VVold VMDK.  I'm looking more into this, if this is an issue on VMware's side or on Pure's side.  You'd be able to follow a similar process though of recovering from a managed snapshot, you'd still need to copy out the data volume or snapshot of the data volume and overwrite the new volume.  The difference now would be that you wouldn't need to copy the volume out from a FlashArray snapshot.  Stay tuned for more updates on this section though.

With Array Protection Groups

Essentially the exact same process as the SPBM section, so see above.

With Manual Snapshots

Much like the VM section, when a FlashArray Volume is eradicated, so are any manual volume snapshots.  You need a FlashArray protection group snapshot to recover the eradicated Data VVol.  Another great reason to use Storage Policies.  

No Snapshots?

Without FlashArray snapshots, then there is no way to recover that Data VVol from the FlashArray perspective.  Now, maybe you have a backup of the Data VVol with another 3rd party backup provider or have a clone of that VM somewhere.  Then you'll need to use those to recover the deleted VMDK.


Cloning a VVol VM from a point in time snapshot

Alright, almost done with this long KB now.  Woo Hoo!  Next I want to cover how to clone a VM from a specific point in time.  There was a specific snapshot X days ago that I want to clone this VM to.  I'll go ahead and cover this process in a couple ways.  One is with the plugin and then the other is without the plugin.  I would strongly recommend using the plugin for this.

With both methods, it's a good idea to just clone the existing VM.  That way all of the hardware settings and VM configs are mirrored.  You can do this manually, but it's easier to just clone the VM.  In my example I didn't change the Network Adapter or modify the VM itself.  I also did not power it on, as that would cause a disruption to the existing VM and any applications on it.  For the sake of making the image/recording shorter those steps were skipped.  

Here is an example of cloning the VM and I'll be using the same cloned VM in both examples.  I'll also be using a managed snapshot as the Point in Time I want to use.

>> Click to expand the Clone Example.
Clone VM.gif

Alright, lets get to the examples. 

With the Pure vSphere Web Client Plugin

With the Pure vSphere Web Client Plugin you can easily import or overwrite a VVol VMs Virtual Disks.  Navigate to the FlashArray Virtual Volume Objects tab on the VVol VM and you can manage these workflows from there.

>> Click to expand the example that uses the Plugin.
Here virtual disk 1 on the cloned VM is getting overwritten with a snapshot of virtual disk 1 on the original VM.
PiT VMDK 1.gif
Here virtual disk 2 on the cloned VM is getting overwritten with a snapshot of virtual disk 2 on the original VM.  The same PiT is used for both Virtual Disk 1 and 2.
PiT VMDK 2.gif

Nice and Easy!  Now you can update the network adapter, VM settings, etc (if you haven't already) and power on the VM to make sure everything looks good.

Without the Pure vSphere Web Client Plugin

You can still use a Point in Time managed snapshot or FlashArray Snapshot to overwrite that cloned VM without the Plugin.  However, you will need to log into the FlashArray in order to overwrite those volumes.  In the example below Data VVol 1 is Data-59092202 and Data VVol 2 is Data-a6a5c589.  

>> Click to expand the example without using the Plugin.
Here are the two Data VVols that I will need to overwrite on the FlashArray.
VVol KB - 16 - VVol-VM-1 - PiT Clone 01.png
I am going to use these two volumes to copy out.  They are from a Managed Snapshot.  Alternatively I could use an array based snapshot, I would just need to locate the correct data volumes to copy out.
VVol KB - 16 - VVol-VM-1 - PiT Clone 02.png
These are the two data VVols that are going to be overwritten.
VVol KB - 16 - VVol-VM-1 - PiT Clone 03.png
Here is an example of overwriting data VVol 1.
PiT FA Recovery 01.gif
And here is an example of overwriting data VVol 2.
PiT FA Recovery 02.gif

The plugin workflow is a bit easier and quicker to run through.  You also won't need to log into the FlashArray to run through the workflow.  Overall I'd strongly recommend using the plugin for these workflows if they are one offs or exceptions.  If this workflow is something that will be happening often or needs to happen often, then PowerCLI or vRO would be recommended.  Once some blog posts or other KBs are done with those workflows we'll update this KB to reflect them.


Importing a Virtual Volume into another VM

Here we can go through the process of importing a VVol VM's Virtual Disk into another VVol VM.  The process is very simple with the Pure vSphere Web Client Plugin, so that's the method that I'll be covering.

With the Pure vSphere Web Client Plugin

The plugin includes a workflow to import a Data VVol from one VVol VM into another VVol VM.  The workflow can use the current Data VVol or copy out from managed snapshots or array based snapshots.  If you need to leverage file quiescing, you can take a managed snapshot and then use that copy of the data VVol to import to another VM.

>> Here is the Workflow to import a Data VVol to VVol VM: (click to expand)
Navigate to the VM you want to import the Data VVol to, click on FlashArray Virtual Volume Objects and then click on Import.
data vvol import 01.gif
Navigate to the source Data VVol (in this case it was VVol VM 2's Virtual Disk 2), locate the snapshot to be used as the source and then click create.
data vvol import 02.gif
Now the Data VVol has been imported, jobs done.

A straightforward process. This can be done manually on the FlashArray as well, but you would need to first create the new VVol Virtual Disk in vCenter, then log into the FlashArray, copy the name of the new Data VVol, then copy out the source Data VVol and overwrite the new one.  That process has been covered in several of the sections here.  It would be the same process, but you would be using the source from another VVol VM.  I prefer to use the plugin but PowerShell and vRO are another option.


 

Closing Thoughts

Use storage policy based management (SPBM)...seriously.  Policy based management of your VVol VMs will unlock many of the great features of VVols.  Then also use the Pure vSphere Web Client Plugin.

Another point I'd like to make is that while a lot of these workflows take a bit of work to go through, Pure does want to make them as simple as we can in the future.  We are working on getting more of these workflows implemented in both the vSphere Client Plugin and vRO.  As these workflows are improved in the future, this KB will continue to be updated.