Hello, my name is Chance Bingan. I'm a senior technical marketing engineer for virtualization at NetApp. Here we are again at Lake Betts on the NetApp campus in Research Triangle Park, North Carolina. I haven't done a Lakeside video in a while, so I figured we were long overdue. Hopefully, you've seen some of my Lakeside videos before, and if you haven't, just search for NetApp with Tanoo videos, and they'll be in the top of the results. But today I'm excited to announce that the ONAP tools 9.10 Vasa provider now has the ability to import valls from unmanaged volumes. This new capability was designed specifically for use with NetApp SnapCenter to allow it to back up and restore valls based VMs as well as use Snapmir and other NetApp technologies to manage data. But it doesn't just stop with SnapCenter. You can absolutely write your own code to backup, replicate, and import vivolves using your own automation tools. Taking advantage of the new REST APIs, onep tools now empowers you to deliver new customtailored storage services for enterprise applications through your own private cloud with expanded options for backup and recovery, replication, even disaster recovery. You can even combine them with SnapCenter using the SnapCenter plugin for VMware's own REST APIs. Of course, we also still support VMware site recovery manager with both vivols and traditional storage. So, you can take advantage of that option as well. This is kind of a big deal because traditionally this has been, you know, a common workflow for old school NAS or sand storage. But with Vivalls, it's a different animal because the Vasa provider that makes Vivalls possible must be able to understand the nature of a Vivvall in a very deep way to enable all the goodness that comes with storage policybased management. With that said, what I'd like to show you today is a short demo of importing a vivol from a snap mirror replica and attaching it to an existing VM so that the guest OS user can recover files from it. Now in my case I am using SnapCenter to create and replicate the snapshots but you can obviously code that on your own as well or like I said integrate SnapCenter into your private cloud using its REST APIs as well. So as usual let's head back inside log into the lab and see how this works. Starting off at the VSCenter home screen we'll go confirm our test VM has the correct tag assigned. You can see I created a custom tag category for SnapCenter and assigned a tag called backup daily. Jumping over to resource groups in SnapCenter, you can see I created one called tag RG. And when we click on it and look at the top right, we can see the backup daily tag. If we go over to policies, we can see the policy we've selected for the backup job and we can see that we are updating snap vault with the backup. In the interest of time, I've already cloned the volume from a snap year replica. And now there are lots of examples on the internet of doing that. So there's no need to cover it here. Okay, this is my vivvall's data store. This one is NFS, but it could be SAN as well.This is the VM we're going to use. Clone workstation. You can see all of its files, and we can see that it is the only VM on the data store in this case. Of course, it wouldn't be like that in production, but that's okay for today. Here we can see that VSCenter shows it has two VMDKs attached, one for the OS and one for data. And if we jump over to the PowerShell isse, you can see the name I have defined for the temp data store I'm going to create. And throughout, I'm going to use the same name for the flex clone and its data store to make things easy. Hopping over to ONAP system manager, we can see the flex clone volume. I've defined variables for the VM name and SVM name. [snorts] And here you can see where I define the VVA's data store to create using the flex clone. This is converted to JSON and used with the invoke-est method command lit. Next, let's look at the syntax to import a vivvall. Here using the new temp data store, we are in essence creating the VMDK descriptor file of a data vall type which points to the actual vivvall data file uh referenced by the new uyuid I generated previously in the script. And if we look back, here's where I generated a new random UID based on the original UI UU ID [snorts] um for hard drive 1 on the VM. If we look into the guest OS, we can see the OS drive and the data drive which is disk one as mentioned previously. Okay. So let's go ahead and run the script. This is the session I have authenticated with using vSphere authentication and we'll be using it for most of the work and you can see this has generated task ID number 11. I built a pause into the script so we can go and take a look at the task status.If we go over to the ONAP tools swagger UI, we can authenticate with that session ID and check on task ID 11. And we can see it's running. Okay. And now it's completed and we can see the vivvall's container details like the backing flex for example.We'll say yes and let it continue until the next pause that I built in for the demonstration. We'll go over to vsenter and confirm that yes the data store is created. So we'll say yes. Next the script adds a folder to store the VMDK file in. Then we go through the UU ID rename and import the vault and add it to the VM. So let's go back and see how it looks. First we can see that the new data store has files for the correct VM registered to it. And if we look at the files, we can see the folder we created and the VMDK in it. And if we jump on into the Windows guest OS, we can see the disc is there. We can online it and it gets a drive letter. We can now recover our files using whatever method the guest OS administrator wants to use. I hope you enjoyed that demo. If you have any questions or comments, please post them in the accompanying blog post or feel free to contact your NetApp account team, NetApp authorized partner or your partner SE. You can also reach out to me directly on Twitter at CB8M data center with the number eight. See you next time.