Introduction
VMware virtual volumes (vVols) have been known in the marketplace for some time now for providing highly scalable solutions for businesses requiring fine-grained controls without the hassle of having to manage storage configurations independently for each VM or even each individual virtual disk.
vVols achieve this by using VMware’s native storage policy-based management, or SPBM for short, which empowers the vSphere administrator to define storage characteristics that match the requirements of the services and applications being hosted by the platform, without having to learn how to be a storage administrator in the process.
SPBM leverages the vSphere API for Storage Awareness (VASA), which was first introduced by VMware along with NetApp support back in 2012. Vendor specific VASA Providers provide an out of band command and control path for both storage management and awareness. With NetApp ONTAP, the VASA Provider is implemented as part of the ONTAP tools for VMware vSphere appliance. ONTAP tools facilitates management of many ONTAP clusters with just a single appliance, minimizing the number of VASA Providers and SSL certificates that vCenter must manage.
With the release of ONTAP tools 9.10, and SnapCenter plugin for VMware vSphere (SCV) 4.6, NetApp introduces a first party solution for backing up and recovery vVols based VMs using storage-based snapshots and native replication to a second ONTAP system using NetApp SnapMirror technology. Another powerful new feature for the IT service provider unique to vVols based VM backups is tag-based resource groups. More on that below.
NetApp storage snapshots are incremental forever type snapshots, and SnapMirror transfers are also incremental forever after the initial baseline. Furthermore, SnapMirror preserves storage efficiency savings from deduplication and compression, which saves time and money for environments that pay for network ingress or egress bandwidth.
Back in 2020, version 9.7.1 of the VASA Provider added support for replication using SnapMirror, but only when used in conjunction with VMware Site Recovery Manager (SRM).
But what if your organization doesn’t use SRM or even SCV? But rather, writes its own code for disaster recovery, replication controls, backup and recovery, or more?
New REST API support in ONTAP tools 9.10
ONTAP tools and SCV are designed to accelerate the journey to cloud-scale automation by not just providing simple, intuitive, and insightful UIs that help the vSphere admins on the operations team, but also by exposing functionality via RESTful APIs allowing automation engineers to quickly and easily adapt storage management to their cloud service catalog.
One example could be creating a new datastore using iSCSI. With traditional automation, you must do the following tasks, keeping in mind you must select all the correct options along the way.
Without ONTAP tools for VMware vSphere:
- Configure ESXi iSCSI initiator to log into iSCSI target
- Create igroup in ONTAP
- Add IQNs to igroup
- Create FlexVol
- Create LUN in FlexVol
- Map LUN to igroup
- Rescan HBAs in ESXi
- Create datastore in ESXi
With ONTAP tools for VMware vSphere:
- Authenticate VMware session with secure REST API endpoint
- Use authenticated session to send REST API to create datastore
- …. No, that’s it.
But that’s not really what I wanted to blog about today. This basic functionality has been there for years. You can see some more examples of ONTAP tools REST APIs with Ansible on GitHub, and I definitely recommend getting familiar with it. You can also use the Swagger UI, which is conveniently linked to from the ONTAP tools “Getting Started” page.
What’s new is the context of this blog post is that ONTAP tools is now able to import a vVol from unmanaged storage using REST APIs. And in fact, currently, only REST APIs. This is important because a vVol isn’t just a LUN or file. It also exists within the VASA Provider’s database. So, in essence, this new API allows you to take a VMDK vVol data file, generate a new VMDK descriptor, and import it into the database. Only then are you able to manage it as you would any other disk.
The practical implication is that this allows you to snapshot and replicate vVols datastores the same way you have always done with traditional datastores, and still automate recovery tasks with vVols datastores the same way you would with any other traditional datastore. Only now you can take advantage of the full power of SPBM and VASA-based storage accelerations that I’ve talked about in previous posts.
Demo
In the following video, I’m going to illustrate the process of attaching a vVol from a SnapMirror replica in order to recover a guest file, such as an application database or other user data. To do so, I’m going to use the new tag based backup policies in SCV to automatically snapshot and replicate a VM based on the requirements I have set forth in my fictional private cloud. For example, I could setup my backups in SCV to look for a tag called “hourly_with_SM” and this backup would run on the hour and update SnapMirror when it is finished. This is important for the cloud service provider because now you only need to tag VMs with the desired policies and SCV will make it happen regardless of which datastore they live on, just so long as it’s an ONTAP vVols datastore. Remember, SCV has its own set of REST APIs that allow you to control backup and recovery services, so this can all be automated within your private cloud environment.
After that, I am going to run a PowerShell script that performs the following tasks for me:
- Clones the SnapMirror destination volume using a standard ONTAP PowerShell Cmdlet (REST APIs also exist for this if you don’t use PowerShell)
- Add the volume as a new temporary vVols datastore using an ONTAP tools REST API and the PowerShell Invoke-RestMethod Cmdlet
- Create a new VM folder in the temporary datastore using VMware’s PowerCLI to store the new VMDK descriptor file
- Rename the VMDK data file with a randomly generated ID# to recover to avoid any chance of a UUID conflict
- Execute the new vvol/import REST API to register the vVol with the VASA Provider
- Use PowerCLI again to add the vVol to the VM so that the end user can recover their files
A few code snippets I’ll share from the script in case you want to copy and paste for your own testing. This isn’t the whole script, just the important parts.
I’m skipping step 1 since that is already well known and documented
Step 2
Note that $headers includes my authenticated session info, and also $Datastore is the name of the FlexClone volume which I am also using as the datastore name for consistency. All fields shown here are required.
ProfileID is the ID of the storage capability profile. If you don’t know it, you can use the /api/rest/1.0/admin/storage-capabilities REST API to get them. For example:
$SCP = Invoke-RestMethod -SkipCertificateCheck -Uri "https:// <my VP address>:8143/api/rest/1.0/admin/storage-capabilities" -Method 'GET' -ContentType 'application/json' -Headers $headers -ErrorAction Stop
A helpful tip is that the targetMoref is the MoRef (Managed Object Reference ID) of the host or cluster you want to mount the datastore on. In this example, it’s a cluster. You can find the MoRef of a host or cluster using PowerCLI, or you can simply peak at the URL in the vCenter UI when selecting the host or cluster.
One other thing is that I am outputting the task ID, just in case something goes wrong and I need to debug later. It isn’t required, but I think it’s always good to include debugging tips.
#Define new DS from cloned volume
$BodyDS = @{
vvolDatastoreRequest= @{
clusterIp= $clusterIp
defaultSCP= "AFF_Default"
description = $null
existingFlexVolList= @(
@{
flexvolName= $Datastore
profileId= 9999954
}
)
name= $Datastore
protocol= "nfs"
targetMoref= "domain-c485"
vserverName= $SVM
newFlexibleVolumes= $null
replicationSchedule= $null
replicationType= $null
}
} | ConvertTo-Json -Depth 4
Write-Host $BodyDS
#Invoke the DS REST API in ONTAP tools
$DSTask = Invoke-RestMethod -SkipCertificateCheck -Uri "https://<my VP address>:8143/api/rest/3.0/admin/datastore" -Method 'Post' -ContentType 'application/json' -Headers $headers -Body $bodyDS -ErrorAction Stop
write-host " "
Write-Host "Task ID:"$DSTask.taskId
Step 3
In my script, I have defined $VM at the very beginning. In practice, this would be a variable passed from your cloud service portal.
Write-Host "Add folder to store the vVol we plan to register"
connect-viserver $viserver -Credential $myCredentialsObject
Start-Sleep -s 10
$DatastoreMOREF = (Get-Datastore $Datastore).Id
$DatastoreObj = Get-Datastore $Datastore
mkdir -Path $DatastoreObj.DatastoreBrowserPath -Name $VM
Step 4
Note that in this case, I have decided to import a copy of the second VMDK, identified as $hdVvolId[1], and I am using the NetApp PowerShell Toolkit Cmdlet Rename-NcFile to do the rename.
Write-Host "identify vVol UUID"
$vmdata = get-vm $VM
$hd = $vmdata | get-harddisk
$hdVvolId = $hd.ExtensionData.Backing.BackingObjectId
Write-Host "vVol ID for second disk"$hdVvolId[1]
Write-Host "Rename file to avoid UUID conflict"
$RandomNumber = Get-Random -Minimum 100000000000 -Maximum 999999999999
$NewvVolUUID = $hdVvolId[1].Substring(0,32)+$RandomNumber.ToString()
Write-Host "New vVol UUID"$NewvVolUUID
$OldPath="/vol/"+$Datastore+"/"+$hdVvolId[1]+".vmdk"
Write-Host "Old path"
$OldPath
$NewPath="/vol/"+$Datastore+"/"+$NewvVolUUID+".vmdk"
Write-Host "New path"
$NewPath
Rename-NcFile -Path $OldPath -NewPath $NewPath -VserverContext $SVM
Step 5
Write-Host "Register vVol"
$BodyImport = @{
vmVVolData= @{
vmName= $VM
vmw_vmID= $null
vvols= @(
@{
ancestorRelationship= $null
clusterName = $null
clusterUuid = $null
datastoreMoRef = "Datastore:"+$DatastoreMOREF
datastoreName = $Datastore
filePath = $null
flexVolName = $Datastore
flexVolUuid = $null
keyValuePairs= @(
@{
key = "VMW_VVolName"
value = "Clone-Wks_2.vmdk"
},
@{
key = "VMW_VVolType"
value = "Data"
})
osType = $null
protocol = $null
san = "false"
sizeInMB = 4096
spaceSetting = "Thin"
svmName = $null
svmUuid = $null
targetflexVolName = $null
targetflexVolUuid = $null
type = "DATA"
uuid = $NewvVolUUID
vmStorageProfileNames = @("VVol No Requirements Policy")
vvolName = "Clone-Wks_2.vmdk"
})
}
} | ConvertTo-Json -Depth 5
$BodyImport
Invoke-RestMethod -SkipCertificateCheck -Uri "https://<my VP address>:8143/api/rest/3.0/admin/vvol/import" -Method 'Post' -ContentType 'application/json' -Headers $headers -Body $BodyImport
Step 6
Write-Host "Add vVol to VM"
$RecoveryvVol = (Get-HardDisk -Datastore $Datastore).Filename
write-host " "
write-host "Recovery vVol is:" $RecoveryvVol
New-HardDisk -DiskPath $RecoveryvVol -VM $VM
References:
vVols concepts - https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.storage.doc/GUID-EE1BD912-03E7-407D-8FDC-7F596E41A8D3.html
vVols getting started guide - https://core.vmware.com/resource/vvols-getting-started-guide#sec6579-sub1
VASA Providers - https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.storage.doc/GUID-8776CF33-ECF8-4541-9221-1F14898B121C.html
SRM adds support for vVols - https://blogs.vmware.com/virtualblocks/2020/07/02/srm-vvols-and-automatic-protection/
VMware PowerCLI - https://developer.vmware.com/powercli
SnapCenter plugin for VMware resource group configuration - https://docs.netapp.com/us-en/sc-plugin-vmware-vsphere/scpivs44_create_resource_groups_for_vms_and_datastores.html
Looking up Managed Object Reference (MoRef) in vCenter Server - https://kb.vmware.com/s/article/1017126
Get familiar with ONTAP Tools RestAPI with Ansible https://github.com/NetApp-Automation/ONTAP_Tools_Datastore_Management/blob/main/roles/ontap_tools/tasks/main.yml [TS1]