The FlashArray Workflow Package for vRealize Orchestrator has been updated to include two new objects:
- Auto-expand datastore policy template
- Workflow to run UNMAP on a datastore
The creation of the first part is explained in this post. But if you are using the FlashArray it is all built into the package, so you have to do very little work. I’ll explain in a bit.
The UNMAP workflow is generic–it can be used with any VMFS datastore that supports UNMAP. So it is included in the workflow package and it is also standalone for those of you who don’t have a FlashArray. You can get the standalone here:
https://github.com/codyhosterman/orchestrator/blob/master/vmfsunmap.workflow
Auto-expand Policy Template
This release of the workflow package includes a template that you can deploy a policy from. This policy will do the following:
- When started will monitor a specific vCenter SNMP target for traps. You of course need to configure that target to send SNMP traps (info on that here for vCenter is also in that previous post).
- When a capacity alert is received (that alert needs to be named “vRO AutoGrow Alert”), the policy will identify the datastore object that it relates to. It will then kick off the workflow “Expand FlashArray/VMFS Volume” that is built into the workflow package.
- That workflow will identify the FlashArray that hosts the datastore and the volume. It will expand (by default) the volume by 30%. That value can be changed. If the expansion results in the VMFS becoming more than the VMFS limit of 64 TB, the process will fail. It will then rescan an ESXi host that sees the datastore, and run a VMFS Volume grow to use the additional capacity. The alert will then be reset to green!
See a demo of it here:
UNMAP from vRealize Orchestrator
This is a simple one–but one I have been wanting to get around to for quite some time. Running UNMAP on a datastore from vRO! In vSphere 6.0 VMware added (see a post from William Lam) an SDK call for running UNMAP (yay!) which opened up what you could do. UnmapVmfsVolumeEx_Task can be called to any ESXi 6.0 host to reclaim dead space using the vCenter SDK.
So using this, I built a quick workflow. This work flow takes in a datastore and looks for an ESXi 6.0 host that sees it, grabs the first host it finds then runs UNMAP. The workflow will wait until the operation is done. The operation does not advertise progress, so it is hard to say when it will finish.
Pretty simple code:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
System.log(“Identifying an ESXi 6.0 or later host to run UNMAP for this datastore.”); for (var i=0; i <datastore.host.length; i++) { var host = datastore.host[i].key; if (host.config.product.version.substring(0,1) >= 5) { var unmapHost = host var esxiSixhost = true; System.log(“Identified an ESXi 6.0 or later host”); System.log(“Running UNMAP process on host named “ + host.name); break; } } if (esxiSixhost == true) { var dsUuid = []; dsUuid.push(datastore.info.vmfs.uuid); System.log(“Running UNMAP process on datastore “ + datastore.name + ” host named “ + unmapHost.name); var unmapTask = unmapHost.configManager.storageSystem.unmapVmfsVolumeEx_Task(dsUuid); while(unmapTask.info.state.value == “running”){} System.log(“Space reclamation complete”); } else { errorCode = “No ESXi 6.0 or later hosts found for this datastore” throw(errorCode); } |
This is built into the workflow package. But I figured people using other storage systems might want to use it too, so I made it available for download separately too.
https://github.com/codyhosterman/orchestrator/blob/master/vmfsunmap.workflow
I do plan on enhancing it somewhat specifically for the FlashArray, to make capacity reports etc. But that’s for the future.
One note of caution. The vCenter SDK call does NOT support changing the block count. So it uses the default block count of 200 always. So this can drastically slow down the UNMAP process on a variety of storage systems. So FYI.
