I recently saw a post on Reddit about pulling a VM storage policy from a VM using vRO and it was stated that it was not possible which was said to be confirmed by VMware support.
‘Now I don’t know when they asked VMware support, and if it was two years or so ago, then that was true. But it is certainly not true now. Though I will admit, it is not super intuitive to figure out unless you know where to look. Here is how you do it.
Btw, I only tested this with VVol storage policies, but it really should not matter at all.
Ok finally! I had this finished awhile ago, but I wrote it using our version 2.0 plugin–so I couldn’t post it until the plugin was certified by VMware. That plugin version is now certified and posted on the VMware Solution Exchange (see my post here).
Moving forward, we will likely be posting new workflows in various packages (working on an ActiveCluster one now), instead of including them directly in our plugin. This will make it easier to update them and add to them, without also having to generate an entire new plugin version.
So first, download and install the v2 FlashArray plugin for vRO and then install my workflow package for VVol on the VMware Solutions Exchange:
Core to most scripting with the FlashArray is figuring out what volume is on what FlashArray. Then you proceed to do what you need with it (snapshot, report metrics, whatever).
Traditionally how this was done, at least from a VMware perspective was via the NAA (network address authority). You take this number, which is how ESXi uniquely addresses a volume and slice it up to find the array serial and the volume serial. By matching the section with a particular array serial, you have identified what array owns it. Then you can make the calls to that array.
Details on how this worked are beyond the scope of this post, but you can see this here:
Amidst writing a vMSC guide for our newly-introduced Active-Active replication called ActiveCluster, I have been taking some breaks to finish my vRealize Orchestrator Workflow Package for Virtual Volumes. I posted a starter post recently:
Over the past few weeks, I have been working on writing a vRealize Orchestrator workflow package for Virtual Volumes and the FlashArray. While that is not quite ready to go out, I think some basics for starting to use vRO and VVols are worth noting.
There are three main parts of using VVols with vRO:
Core vCenter SDK–this is what you use to create VMs, datastores, etc.
SMS–this is the service that manages storage providers (VASA) and replication for VVols.
PBM–this is the service that you use for storage policy based features.
So over the past two years or so I have been talking up vRealize Orchestrator quite a bit. And a fair amount of that conversation was based on the eventual usage of vRealize Automation. While I certainly feel vRA is a GREAT use case for vRO, the usefulness of vRO does not in any way require vRA.
A common question I get is, “hey can you add this feature to the official FlashArray Plugin?”. The answer is often “maybe” or “eventually” but sometimes even “no”. The plugin is centered at the satisfying the majority and therefore sometimes does not exactly meet your requirements.
So with these two things in mind, what is the connection? Well, using vRO (which is FREE when you have vCenter) you can easily build your own. Especially when you install the FlashArray vRO plugin.
I see a couple advantages here:
Start learning vRO. Using default workflows so you don’t have to “code” anything. Then start with some more customization as you become familiar.
Provide tailored workflows in the vSphere Web Client
Interface-agnostic workflows. As you move forward and use the HTML-5 interface, or vRA you don’t have to redo your work.
I normally do not create a blog post about updating the guide, but this one was a major overhaul and I think is worth mentioning. Furthermore, there are a few documents I have written and published that I want to mention.