Being a diligent admin, I always unmount a datastore from an ESXi server prior to completely deleting it. It's a good way to verify the datastore isn't being used before the storage admin removes the ESXi server's visibility to the lun. This is a task that I really want to perform in vRealize Orchestrator (vRO) instead of having to unmount the datastore from the ESXi server manually. SPOILER ALERT - I'll include a workflow that allows you to execute the unmount across multiple ESXi servers in parallel at the end of this post.
The first step is to see what's available from an unmount standpoint. We start by bringing up the API Explorer under the Tools menu.
From here we can search the "Attributes & methods" for text that contains the word unmount. There quite a few methods which contain the text unmount. I'm going to focus on the VcHostStorageSystem.unmountVmfsVolume() method.
This method takes a single argument - the uuid of the VMFS datastore that we are unmounting. So, the next step is to search for attributes that contain the text uuid. For this, we'll use the VcHostVmfsVolume.uuid attribute. We can get to this attribute using the by traversing the datastores "info" (VcDatastoreInfo) attribute and then the vmfs (VcHostVmfsVolume) attribute.
Now that we can get the uuid value for the datastore we can start doing some actual programming. I want to provide reusable method (i.e. Action) that anyone can use in a workflow. To do that we change from "Run" to "Design" view and then select the "Action" icon in the designer UI. Right-click on the folder where you want to place the action (or create a new folder) and select "Add action..."
From here, click on the yellow arrow to add parameters. The first parameter is the vmhost and the second is the datastore. Make sure to set the parameter types correctly - the default type is string which is not correct for our parameters. Then we add a small piece of code to unmount the datastore from the vmhost.
Now that we have coded the action, we go back to the Workflow designer to create a "New workflow"
Just like before, we add two parameters (vmhost and datastore) and just like before we have to set the parameter types correctly.
BONUS!! One of the features I really like with vRO (and vCO) is the presentation. This allows you to the customize input form when the workflow is executed. We'll start by adding a description under the General tab for both the vmhost and the datastore. This text will be displayed when the workflow is executed. Next we add properties to both the vmhost and the datastore. For the vmhost, we'll add only the "mandatory input" property so that the workflow cannot be started if this parameter is omitted.
For the datastore, we add the mandatory input but also add the "specify a root object to be shown in the chooser". This filters what is displayed based on the vmhost that is selected as the first parameter.
Now we go to the Schema tab and drag the "Action element" into the workflow. In the search filter we look for unmount and find the action we created in the step above.
This *should* synchronize the parameters for us.
I also drag the "Throw exception" element over the top of my unmountDatastoreFromVmhost so that the workflow will throw an exception if an error occurs during the unmount. If you want to include additional text for the error then you can edit the exception and add your text to the "Business status" box.
We're now ready to execute the workflow. This can be done by clicking on "Run" at the top of the Schema window. In the pop-up window click on vmhost parameter "Not set" to select the ESXi Server to unmount a datastore.
Now, click on datastore parameter "Not set" to select a datastore. You'll notice that the root object in the ESXi server you selected in the step above - just like we planned thanks to the workflow presentation. Finally, click the Submit button to execute the workflow.
By creating this simple workflow to unmount a datastore from a ESXi server we could then do a few of things:
From here we can search the "Attributes & methods" for text that contains the word unmount. There quite a few methods which contain the text unmount. I'm going to focus on the VcHostStorageSystem.unmountVmfsVolume() method.
This method takes a single argument - the uuid of the VMFS datastore that we are unmounting. So, the next step is to search for attributes that contain the text uuid. For this, we'll use the VcHostVmfsVolume.uuid attribute. We can get to this attribute using the by traversing the datastores "info" (VcDatastoreInfo) attribute and then the vmfs (VcHostVmfsVolume) attribute.
Now that we can get the uuid value for the datastore we can start doing some actual programming. I want to provide reusable method (i.e. Action) that anyone can use in a workflow. To do that we change from "Run" to "Design" view and then select the "Action" icon in the designer UI. Right-click on the folder where you want to place the action (or create a new folder) and select "Add action..."
From here, click on the yellow arrow to add parameters. The first parameter is the vmhost and the second is the datastore. Make sure to set the parameter types correctly - the default type is string which is not correct for our parameters. Then we add a small piece of code to unmount the datastore from the vmhost.
Now that we have coded the action, we go back to the Workflow designer to create a "New workflow"
Just like before, we add two parameters (vmhost and datastore) and just like before we have to set the parameter types correctly.
BONUS!! One of the features I really like with vRO (and vCO) is the presentation. This allows you to the customize input form when the workflow is executed. We'll start by adding a description under the General tab for both the vmhost and the datastore. This text will be displayed when the workflow is executed. Next we add properties to both the vmhost and the datastore. For the vmhost, we'll add only the "mandatory input" property so that the workflow cannot be started if this parameter is omitted.
For the datastore, we add the mandatory input but also add the "specify a root object to be shown in the chooser". This filters what is displayed based on the vmhost that is selected as the first parameter.
Now we go to the Schema tab and drag the "Action element" into the workflow. In the search filter we look for unmount and find the action we created in the step above.
This *should* synchronize the parameters for us.
I also drag the "Throw exception" element over the top of my unmountDatastoreFromVmhost so that the workflow will throw an exception if an error occurs during the unmount. If you want to include additional text for the error then you can edit the exception and add your text to the "Business status" box.
Now, click on datastore parameter "Not set" to select a datastore. You'll notice that the root object in the ESXi server you selected in the step above - just like we planned thanks to the workflow presentation. Finally, click the Submit button to execute the workflow.
By creating this simple workflow to unmount a datastore from a ESXi server we could then do a few of things:
- provide storage admins access to the workflow through either the vRO GUI or through the vSphere Web client to execute the workflow
- create a workflow that loops through multiple ESXi servers to unmount a datastore
- create a workflow that loops through multiple datastores and unmounts those from a single ESXi server
- create a workflow that loops through multiple datastores and unmounts those from multiple ESXi servers
Item #2 is the one that interests me. If a datastore needs to be unmounted from every ESXi server in a cluster then calling this simple workflow for every ESXi server in that cluster will do the trick. And, if I call this workflow as an "Asynchronous workflow", then ALL ESXi servers will unmount the datastore in parallel! That's exactly what I've done in this workflow package. Simply download the package and import it into your vRO server using the designer UI. That's it!
Are you doing storage refresh and migrating VMs from one storage array to another? That would be the use case for item #4. You can leverage this simple workflow to automate the unmount of the datastores from multiple ESXi severs. Have Fun Orchestrating!
File isn't available any more... ;(
ReplyDeleteThese information were very easy to understand. They were very useful for my business. Keep up the good work.
ReplyDeleteCloud Migration Services
AWS Cloud Migration Services
Azure Cloud Migration Services
VMware Cloud Migration Services
Cloud Migration tool
Database Migration Services
Cloud Migration Services