Web Guide: vSphere Virtual Volume VM Recovery and Snapshot Workflows
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 VM 1 will be using Managed snapshots:
The option to snapshot memory or quiesce the file system are not checked:
Now, looking at the FlashArray for this VVol VM, the two Data Volumes have an additional volume with a -snap suffix:
However, that is just for the Data Volumes. Take note that there is no snapshot or copy of the Config Volume:
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:
Here the storage policy "1 hour replication" is applied to the VM Home (config volume) and the two VMDKs (data volumes):
There is a specific replication group (flasharray protection group) that is selected for all volumes:
The policy has been applied and is compliant:
Looking at the FlashArray for VVol VM 2, notice that there are not any -snap volume copies and there are no volume snapshots found:
However, look at the individual volumes (Config and Data) and you will see that the volume is part of a Protection Group as expected:
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:
Again, very similar to VVol-VM-2, no volume snapshot for the VVol VM:
And here we see that the Config Volume is part of a protection group and there is a snapshot of the Config Volume:
With VVol-VM-4 we will be doing some manual snapshots (using the Pure web client plugin):
We will take a manual snapshot of both the boot volume and the second vmdk:
On the FlashArray we can see that there are snapshots for both Data volumes:
However, there are no snapshots for the Config Volume:
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:
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:
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:
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:
With VVol-VM-2 there is the E drive labeled as VM-2-Volume and there are three files that are the same size:
With VVol-VM-3 there is the E drive labeled as VM-3-Volume and there are three files that are the same size:
With VVol-VM-4 there is the E drive labeled as VM-4-Volume and there are three files that are the same size:
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:
- Recovering a Deleted VVol VM within 24 Hours
- Recovering a Deleted VVol VM after 24 Hours
- Recovering a Deleted VVol VM VMDK within 24 Hours
- Recovering a Deleted VVol VM VMDK after 24 Hours
- Cloning a VVol VM from a point in time snapshot
- 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:
After the VM is powered off, it is then deleted from disk:
This same process is used for each of the VMs:
After the VM is powered off, it is then deleted from disk:
Then, from the FlashArray, we can see the Volume Groups and Volumes pending eradication:
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:
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:
Select VVol-VM-2's Volumes and then Recover:
Once Recovered, the Volume Group for VVol-VM-2 will show the Config and two Data volumes as part of that Volume Group:
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:
Select all of the volumes and then recover:
Now the Volume Group will show that each of the destroyed Volumes are recovered:
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:
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:
Then Select the Config VVol:
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:
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:
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:
After the VM is registered, navigate to the VM page, select the recovered VM and then Power the VM on:
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:
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:
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
Create a new Virtual Machine:
Give it the name of the deleted VM and the location for the VM:
Choose the Compute Resource (match with what it was previously):
Select a storage policy and the VVol Datastore that the deleted VM was on:
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:Review all the information, make sure it looks right and then finish:
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:
Then from the new VM's Volume Group, note the name of VMDK 1 and VMDK 2 Data Volumes (copy them down somewhere):
From the recovered Volume Group identify the Data Volumes for VMDK 1 and VMDK 2:
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:
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:
Again, confirm that the correct data volume is getting overwritten then proceed:
Then proceed to do the same thing for the Data volume for VMDK 2:
Confirm that the correct Volume Group and Data Volume name are being used:
Navigate to the New Volume Group and notice that the two Data volumes have an updated source volume:
Back in vCenter, select the VM that was created and power it on, VVol-VM-1 is used in this example:
After the VM is powered on, log in and confirm that the application and files look good:
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.
- From the FlashArray, recover the Volume Group
- From the FlashArray, recover the Volumes in the recovered Volume Group
- From the FlashArray, navigate to the recovered Volume Groups Config Volume
- From the FlashArray, select the snapshot to recover the Config volume from and then recover the Config Volume
- From vCenter, refresh the VVol Datastore's files, then navigate to the Recovered VM
- From vCenter, register the Recovered VM's vmx file
- 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.
- From the FlashArray, recover the Volume Group
- From the FlashArray, recover the Volumes in the recovered Volume Group
- From vCenter, create a new VVol VM with the same configuration (CPU, Memory and VMDKs) as the deleted VM
- From the FlashArray, navigate to the new Volume Group, get the Volume Name for each Data Volume
- From the FlashArray, navigate to the recovered Volume Group, select the Data Volume for VMDK 1
- From the FlashArray, copy the Data Volume for VMDK 1 to overwrite the Data Volume on the new Volume Group for VMDK 1
- Repeat for any additional VMDKs as needed
- From vCenter, select the new VM that was created and power on the VM
- 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.
- From the FlashArray, recover the Volume Group
- From the FlashArray, recover the Volumes in the recovered Volume Group
- From the FlashArray, navigate to the recovered Volume Groups Config Volume
- From the FlashArray, select the snapshot to recover the Config volume from and then recover the Config Volume
- From vCenter, refresh the VVol Datastore's files, then navigate to the Recovered VM
- From vCenter, register the Recovered VM's vmx file
- 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.
- From the FlashArray, recover the Volume Group
- From the FlashArray, recover the Volumes in the recovered Volume Group
- From vCenter, create a new VVol VM with the same configuration (CPU, Memory and VMDKs) as the deleted VM
- From the FlashArray, navigate to the new Volume Group, get the Volume Name for each Data Volume
- From the FlashArray, navigate to the recovered Volume Group, select the Data Volume for VMDK 1
- From the FlashArray, copy the Data Volume for VMDK 1 to overwrite the Data Volume on the new Volume Group for VMDK 1
- Repeat for any additional VMDKs as needed
- From vCenter, select the new VM that was created and power on the VM
- 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.
- From the FlashArray, recover the Volume Group
- From the FlashArray, recover the Volumes in the recovered Volume Group
- From vCenter, create a new VVol VM with the same configuration (CPU, Memory and VMDKs) as deleted VM
- From the FlashArray, navigate to the new Volume Group, get the Volume Name for each Data Volume
- From the FlashArray, navigate to the recovered Volume Group, select the Data Volume for VMDK 1
- From the FlashArray, copy the Data Volume for VMDK 1 to overwrite the Data Volume on the new Volume Group for VMDK 1
- Repeat for any additional VMDKs as needed
- From vCenter, select the new VM that was created and power on the VM
- 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)
-
- Create a new VM; this is covered earlier here.
-
Identify the the new VMs Data volumes, here with VVol-VM-2, Data-440a997f is VMDK 1 and Data-b216fedd is VMDK 2:
-
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.
- 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:
-
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.
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.
To recover the virtual disk, navigate to the VM, click on FlashArray Virtual Volume Objects and then click on Restore Deleted Disk.
Then select the deleted disk and click restore.
Looking at the FlashArray, you'll see that the Volume has been recovered.
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.
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.
- In vCenter, create a new Virtual Disk that is the same size as the VMDK that you destroyed.
- On the FlashArray, recover the destroyed VMDK
- Overwrite the new VMDK - Data VVol - with the Data VVol that was just recovered.
- 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.
Now in vCenter create a new Virtual Disk that is the same size as the recovered Data VVol.
Then copy out the recovered data VVol and overwrite the new data VVol.
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.
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.
Here I log into the VM and refresh the Disks. Then the volume shows back up as mounted and everyone is happy.
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.
-
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.
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.
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.
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.
These are the two data VVols that are going to be overwritten.
Here is an example of overwriting data VVol 1.
And here is an example of overwriting data VVol 2.
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.
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.
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.