Today we released the VMware vRealize Orchestrator Plug-in for Dell EMC PowerMax which is available here for download. For those readers of my blog, you may recall we already have a PowerMax/VMAX plugin for vRO which I wrote about here. This original plugin is only available on GitHub and is open-source, meaning there is no support. While many of our customers are accustomed to developing their own code, others cannot implement an open-source product and therefore the introduction of this supported plugin is welcome news. Like my original post, I’m going to give a brief overview on how to get started with the plugin and follow it up with other posts on specific workflows and vRealize Automation integration.
Let’s start with the prerequisites for the plugin. The PowerMax name really only refers to the operating system, PowerMaxOS. This means we support both the VMAX All Flash running PowerMaxOS and the PowerMax platform. In addition you’ll need:
- Unisphere 9.0 (REST API) – external or internal on the array
- vRO 7.3, 7.4, or 7.5
The plugin is delivered as a vmoapp file and is installed in the vRO Control Center. The screenshots below are from my environment which is a vRA/vRO packaged vApp 7.5. Therefore navigate to the IP/FQDN of the vRA appliance and access the vRealize Orchestrator Control Center menu.
Login as root and select the icon to Manage Plug-Ins.
Here select the PowerMax plugin file from your local operating system (e.g. o11nplugin-dellemc-powermax-220.127.116.118.vmoapp) and Upload (this image also shows the after-install result).
You will need to accept the EULA and then Install.
After installing, the Control Center will notify the user that the service will restart in a couple minutes. So give it a good 5 just in case before trying to access the vRO Client. You can manually restart the service if you are in a hurry.
Once installed, the workflows will be available in vRO. Return to the menu page (first image above) and select the link for the vRealize Orchestrator Client. You’ll login as the administrator. From this point I’m going to assume you’ve operated in vRO. Unlike some other GUI interfaces, this one requires that you understand how vRO works, how to execute workflows, etc., and unfortunately a tutorial is not in order here.
The plugin workflows are consolidated into the following folders:
- Plugin Settings
- PowerMax Discovery
- PowerMax Host Operations
- PowerMax Provisioning
- PowerMax Snapshot Operations
- PowerMax Storage Group Operations
- PowerMax Volume Operations
Outside of a few setup workflows contained in the Plugin Settings folder, the workflows are generally of two types:
- Actions performed only on the array- e.g. creating a host, port group, device.
- Actions performed both on the array and in VMware (vSphere integrated) – e.g. creating a device, adding it to a storage group, then creating a datastore on it.
Unlike the previous plugin, the VMware workflows are interspersed according to the associated array function they perform. For instance, if you want to create a VMFS datastore, you would find that workflow under the PowerMax Provisioning folder.
Another change I’ve highlighted in the image is the description. For those workflows requiring a bit more detail the developers added documentation. If I’m creating a port group, well that’s quite straight forward as is the description. Creating a VMFS datastore from scratch, however, benefits from a detailed explanation.
Be sure, therefore, to read the description before executing. Some workflows will require a prerequisite. For instance if I want to mount a volume as a datastore, I must be sure to select a storage group that is in a masking view or the workflow will fail. The plugin will not filter. And speaking of filtering, there is little of that in the workflows. Filtering is very costly in terms of performance, and there is an assumption that the user knows what he/she is doing, so be sure you do!
If you want to create your own workflows, you can duplicate any of the existing ones, or use the available actions to develop your own:
Even if you can, don’t modify the workflows/actions delivered with the plugin. It will only create confusion. Fortunately I believe we lock them down, but it is best practice to keep your customization separate.
- When adding a management server/array, the plugin will make available all arrays that Unisphere sees. If you use SRDF, chances are that one of those listed arrays is what we call “remote”, in other words no Gatekeepers are presented from the array. Although the plugin will let you add a remote array, there are actions that cannot be executed on a remote array. We therefore only recommend adding local arrays. This will be changed in a future version that supports SRDF workflows so that only local arrays can be added.
- The Logs tab of vRO is very useful. We tend to output anything related to the workflow which would include, for instance, the volume ID of a created device. If I am going to use that device in another workflow, it would behoove me to take note:
In that same vein there is no intelligence in the plugin. If the workflow errors, the Logs tab will show the failed call(s), exactly as received. We won’t prevent you from taking actions either so just keep that in mind as you run the workflows.
- We have a bunch of “List” and “Get” workflows. These will do exactly what they say and get a list of some object, e.g. List Port Groups. For these workflows, the logs are not useful since all you will see is something like this: [2019-03-11 13:41:21.963] [I] Found  port groups on PowerMax array 000197600357. This is because the workflow results output to a variable. In this case a more useful tab is the Variables one where we see the output variable and the result set of port groups.
For the most part, we assume users will not be accessing the vRO Client directly, rather they will be running the workflows from something like vRA, so these output variables would be directed to something else, not accessed here.
I recorded a short demo here of the following:
- Adding a management server
- Adding an array
- Creating a VMFS datastore from scratch
Like the original plugin, you may find the snapshot workflows are most useful for both local backup as well as testing/recovery.
********************** Update 5-21-19
This one has voice over:
Ansible, Python, etc.
In addition to the plugin and in line with development of scripts, cloud, etc., I want to note the great work my colleague Paul Martin does with the Unisphere REST API, Ansible Playbooks, and Python. If you are on this road and would like more information, you can read about Paul’s stuff here.