Version 1.2 of the PowerMax vRealize Orchestrator (vRO) Plug-in is now available for download from our support site or the VMware Marketplace. For those new to vRO or the plug-in, the PowerMax Plug-in allows users to run workflows using the REST API (part of Unisphere for PowerMax) to automate both provisioning and protection, among other capabilities. This release has some great additions, courtesy of our stellar development team! For a general introduction, you can check out the first release here.
If you do not have the plug-in installed yet, the process is easy enough. Access the vRO Control Center and add the new .vmoapp file that you download from the aforementioned websites. VMware will restart the service automatically and you will see the new plug-in and workflows the next time you login to the client (legacy or HTML 5). If you already have the plug-in, I’m afraid the upgrade is as painful as before, in that you have to uninstall and re-install. I went through the steps in the previous post here. I have found in my own environment, where I uninstall and re-install all the time, I had to switch two of the steps. The process calls for first deleting the plug-in in the Control Center and then removing the package. If I use this order, I can’t delete the package, the option is grayed-out, and then I have to make a change to the Postgres DB manually which is never a good idea. So I reverse them, and delete the package first, then delete the plug-in, then do the other clean-up. This works for me. You may not have this problem, but since I did I thought someone else might.
One other thing about support before moving on to the good stuff. The plug-in does not support vRO 8.0. There are a bunch of issues in the vRO GUI client and other concerns with 8.0 that led us to skip certification of this release. We expect that 8.1 will have those resolved and we plan on supporting that release. If your business has some specific reliance on vRO 8.0 such that you cannot use 7.6, yet still need the PowerMax Plug-in, you can open a request with support which will generate an RFQ (request for qualification) and at that point our development and QA can determine the best way to assist you. The best option, however, is to use one of the supported versions (7.4, 7.5, or 7.6) until 8.1 next year.
Now what’s new with the plug-in?
Our plug-in continues adding improvements and features, mostly customer-requested. We have a slew of new and updated workflows which I list below.
These are the new changes to the existing workflows:
- Added port WWN to array port data in Create Port Group and Modify Port Group workflows
- Service level support in storage group workflows (create/modify)
- Idempotent support in selected create/modify workflows
- iSCSI support in Create Port Group workflow
- Array serial numbers displayed in the UI
The following are the new workflows for 1.2:
- Modify Initiator Alias
- End-to-end host provisioning workflows
- Provision volumes to PowerMax host and host group
- Remove access to volumes from PowerMax host and host group on array
- VMware integration workflows
- Add new ESXi host to ESXi cluster
- Remove ESXi host from ESXi cluster
- Provision VMFS datastores to ESXi host and cluster
- Volume level SRDF protection
- Create/delete SRDF protection for individual volumes
- Support to add/remove SRDF protected volumes in Modify Storage Group workflow
So some of these are self-explanatory, some I want to address individually, and then others I will demo.
Service Levels
The ability to set the Service Level on a storage group was very problematic in the REST API which is why its implementation was delayed. I’ve included the HTML 5 interface of the workflow below. Note that in order to see the service levels you will have to select a storage resource pool (SRP). As a general matter, I only use the legacy Java client as frankly I still don’t think VMware has this HTML 5 version on par, but I know many customers like it so I wanted to show it here.
Array serial numbers displayed in the UI
Here’s one I’ve asked for since inception, a better way of filtering. Those of you with a single PowerMax will not have noticed this issue, but if you have more than one array it was a problem. For example, if I wanted to run the workflow to expand device 00086 I would first select my array, then search for the device number as below.
Notice that there are 2 devices shown, because I have two arrays available. By looking at the list, however, I can’t tell which one is from my array. If I hover over a device, it will show me lots of information about each one which will include the array SID, but it is not intuitive.
In the new release, we now prefix all the objects with the array SID which obviously makes it easy to pick the device I want. Again, very helpful for those of us with multiple boxes. You might ask why we just don’t filter by array and that comes down to performance. The architecture of vRO in combination with the REST API would make that type of filtering prohibitive, but this solution, I think, is simple enough.
Volume level SRDF protection
This is one was requested by multiple customers. The current plug-in can protect storage groups with SRDF with a single workflow, but what if I have an existing storage group and I need to not just expand the volumes (which we can do of course), but I need to add a new pair? Well now you can in the Create Volumes. The parameters now include the ability to set the local and remote array and their respective storage groups. Note that this feature does require Unisphere for PowerMax 9.1. The first screen is the same screen as the previous release:
But if you want to enable SRDF for the newly created device, the second screen, SRDF Options, allows you to set the remote array and the remote storage group for up to 2 arrays (3-site configurations).
And voila, the ability to add pairs to an existing SRDF protected storage group.
There is also a new workflow if you need to create a pair manually – for example perhaps you have another a fourth array in your environment. Note my highlight below that, like the above option, it does require the most recent version of Unisphere for PowerMax.
The workflow parameters are straightforward, how many pairs, how big, what SRDF group, etc. Here is the dialog:
So with these changes you’re covered for SRDF in about every way.
Provisioning workflows
The new provisioning workflows are actually updated workflows to both regular device creation and VMFS datastore creation. We took the wizards from Unisphere for PowerMax and now call them in the REST API. The deprecated functionality required a masking view to exist whereas the new workflows allow you to create all, some, or none of the objects on-the-fly, e.g. host group, storage group, port group, and masking view. In addition to the provisioning, development added workflows for the opposite, removal of the devices from the hosts. Here is an example of the workflow:
Demo
Here is the demo of the provisioning workflow. I typically do not do voice overs, but due to the options available in the workflow it was too difficult for callouts, therefore I walk through it. It’s a casual conversation so I hope it is easy to follow along.
Be sure to check out the documentation guides for more detail.
Warning!
There is one workflow I want to call out for its ability to cause grief in your vCenter. As you know, we offer the ability to mount an existing device with a datastore, presenting it to an ESXi host. This workflow is called “Mount Volume as Datastore on an ESXi Host.”
Normally this might be used in a backup situation, where I have a snapshot of a datastore and I am going to mount it to a separate backup host; however you can present the same copy back to an ESXi host which has the original datastore mounted. This is also a normal procedure, but when doing this you must resignature the datastore so there is no conflict between the original and the copy. Our workflow, however, gives you the option to not resignature which you might use in the previous example of the backup server.
When you do not resignature, VMware will force-mount the datastore to the ESXi host. Now there are circumstances where force-mounting may be necessary, BUT if you do not resignature and present the copy to an ESXi host that is in a vCenter where any host can see the original datastore, you will cause all sorts of problems. DO NOT DO THIS. If you accidentally do this, quickly unmount the copy. In a future release we may remove this ability since it can be so detrimental if used incorrectly.
Dell PowerFlex and PowerMax with VMware 