Recently I deployed vRealize Automation 7 (vRA) to see how VVols might integrate with it on the VMAX platform. (Disclaimer – I am by no means a vRA expert, but I have worked with it a bit, mostly with our hybrid cloud.) As you know (or if you don’t check out some of my other VVol posts), VVols are dependent on Storage Policy Based Management. It is how we assign different capabilities to the same VVol datastore. You create policies which each have a particular capability (for VMAX think SLOs), and when you create/clone a VM you select the policy and VMware tells you which VVol datastore is compatible. Upon creation VMware passes the info to the VASA Provider and lo and behold the VM gets the right capability. And though you might have 3 VMs in the same VVol datastore, each one could be assigned a different capability, e.g. Silver, Platinum+OLTP, etc. In fact each vmdk of a single VM could have a different capability. Doing this in the vSphere Web Client is really easy. In fact SPBM has been around for a while – it is the same process you might have used with VASA 1 to categorize datastores according to disk technology (e.g. SATA, EFD). Doing this in vRA 7, however, is not so easy as you cannot use SPBM.
This is not to say, though, that you can’t use vRA with VVols. For instance, when you create a VM in the vSphere Web Client you are under no obligation to choose a storage policy. VMware is perfectly happy to allow you to select the VVol datastore without ever specifying a policy. This is because each VVol datastore has a default capability – for VMAX it will be the lowest performing SLO assigned to the storage container (e.g. Bronze, Optimized) – and when the VM is created it will inherit that default capability. You also can change the default capability to any one available in the datastore (or more precisely to one of the SLOs assigned to a storage resource in the storage container). For instance here my VVol_SC_1 datastore has two capabilities: Gold and Platinum_OLTP As Gold is less performant than Platinum OLTP, it will be the default capability; however I could change it to Platinum if I wished. See this WP for more detail.
Click to enlarge – use browser back button to return to post
Click to enlarge – use browser back button to return to post
So how does this relate to vRA? As part of the setup in vRA you will have to create a reservation which will be tied to the available storage in a vCenter. What you can do, as I did below, is to assign the reservation to the VVol datastore. When I request a VM through my catalog which is tied to this reservation, my VM will be created with VVol storage and assigned my default capability (in this case Gold). Now unfortunately, since there is no SPBM integration, the storage policy will default to VVol No Requirements Policy. This means there is no way for the user to tell what capability the VM has without looking at the default capability of the VVol datastore before creation. My example follows.
Here is the reservation only specifying the VVol datastore.
Click to enlarge – use browser back button to return to post
Here is the default capability for said datastore:
Click to enlarge – use browser back button to return to post
And finally a provisioned VM, vm18, using a catalog item in vRA. Note again the capability is not visible at the VM level so the user would need to know the default capability of the VVol datastore at the time the VM was created.
Click to enlarge – use browser back button to return to post
Now VMware has this slick package available for Storage Policy Based Management with vCAC 6.x and vSphere 5.5.x to do SPBM but obviously without vSphere 6, VVols aren’t in the picture. I actually did try to use it with vRA 7 but didn’t have much luck and after multiple attempts came to the conclusion that I’d have to leave it to VMware. So I reached out to my colleague at VMware @BenMeadowcroft (Product Management VVol) to see if he could shed some light on VVol integration with vRA 7 in case I was just being thick. Turns out my experience was expected. Fortunately VMware is working on a version of the SPBM package that will work on vRA 7 which is great. Perhaps also in the future SPBM will simply be available as standard functionality in vRA but frankly I’ll be happy with the updated package.
So you might ask are there any other options in lieu of the package? I’ve already written about one above, where you assign the desired default capability to the VVol datastore and then all VMs deployed to the VVol datastore will be created with that capability (SLO). This of course is not ideal since if you want a different capability you have to be sure to change the default of the VVol datastore in the vSphere Web Client before submitting the catalog request. In addition, as I mentioned, you won’t be able to tell what the capability of the VM is. To resolve this you could change the VM Storage Policy of the VM after deployment, but that misses the whole point of automation. There are two other options that might be used which help to alleviate this issue.
The first thing we can do is to create VM templates with the desired capabilities and then generate a blueprint/catalog item for each template. For instance here is a template I created with multiple disks and multiple capabilities:
Click to enlarge – use browser back button to return to post
Now in vRA I generate the catalog item for that (I’m assuming the reader has a general knowledge of vRA as the steps are too numerous to include in this post). Recall that my reservation is still tied to the VVol datastore.
Click to enlarge – use browser back button to return to post
After ordering the item, the VM clone is deployed with the same storage policies as the template:
Click to enlarge – use browser back button to return to post
So if in your environment you typically use templates in vRA, then perhaps this option will work, though if the same template will be deployed using different capabilities you would have to generate a template for each require capability. This of course uses more storage and may therefore be undesirable.
A second option I tested which offers greater flexibility for those customers not using templates is to use multiple storage containers on the VMAX, each with their own capability (i.e. one storage resource with the designated capability (SLO) per storage container). We allow up to 16. Each storage container requires a VVol datastore in vSphere. Here is my setup – first the storage containers as shown in Unisphere for VMAX:
Click to enlarge – use browser back button to return to post
After refreshing the VASA Provider, the storage containers are made available within vSphere so the VVol datastores can be created like thus:
Click to enlarge – use browser back button to return to post
Once vRA recognizes the new inventory items (or force a data collection), you create the reservations as well as reservation policies and storage reservation policies. Let’s start with the storage reservation policies. I create a storage reservation policy for each VVol datastore and then assign each one to its correct compute resource – a datastore in this case. In essence I tag each VVol datastore with its SLO. For the first example below storage policy reservations are not required since the vmdk(s) of the VM will all reside in the same datastore. We will use them in the second example. It’s just easier to create both types of reservation policies first.
Click to enlarge – use browser back button to return to post
Now create the “regular” reservation policy for each capability – I used the same names as the storage ones. They are created just like the storage reservation policies – you just change the Type.
Click to enlarge – use browser back button to return to post
Finally we need to create a reservation for each capability. A reservation, unlike a policy, is going to be associated with some compute resources. Here I’ve created a reservation for my Bronze capability. You can see I only select the single VVol datastore to ensure the VM will only be created with the Bronze SLO. Note that in addition to the reservation itself, I also tag each reservation with the reservation policy I created above. The reservation policy is essential since that is what is assigned to the blueprint.
Click to enlarge – use browser back button to return to post
Next I create a blueprint for the Bronze capability. I’m using the vSphere template, and note two things: First I assigned the reservation policy “VVol_Bronze_Policy” to ensure my VM is created in the correct datastore and second that I have not assigned a storage reservation policy since it is unnecessary as my vmdk will already go into the correct datastore.
Click to enlarge – use browser back button to return to post
Now submit the new catalog item (yes I skipped a few steps)…
Click to enlarge – use browser back button to return to post
and our new VM, vm16 is generated in the correct VVol datastore with the Bronze capability. Also see that I have highlighted the storage policy (VVol No Requirements Policy) to point out that we aren’t using SPBM here, rather we are skirting it with multiple datastores. But unlike the first example in the beginning of the post, I know for sure the VM has the Bronze capability because the VVol datastore only has 1 capability assigned.
Click to enlarge – use browser back button to return to post
Let’s quickly return to those storage reservation policies for the second example. Let’s say I want a VVol VM with multiple vmdks with different capabilities. How does that work? It’s quite simple actually. As shown in the Bronze blueprint above, we have the ability to assign a storage reservation policy to each disk listed in the blueprint. All we need is a reservation policy that can be tied to a reservation that encompasses all our VVol datastores. So I create the reservation policy (e.g. All VVol Datastores), and apply it to a new reservation that has access to all the VVol datastores like so:
Click to enlarge – use browser back button to return to post
This new reservation gives us the ability to assign different storage reservation policies to each disk in the blueprint. Here is the blueprint I created. I have boxed the reservation policy, the two vmdks I assigned to the blueprint, and most importantly the checkbox so my users can change where each vmdk is located.
Click to enlarge – use browser back button to return to post
When I submit this catalog item, I can now select one of the previously created storage reservation policies for each disk. In my example I selected Gold for the first disk and Silver for the second.
Click to enlarge – use browser back button to return to post
vRA submits the VM request and our result is VM vm17 below which shows the two distinct VVol datastores in use, though again the storage policy will still reflect the default since SPBM is not involved.
Click to enlarge – use browser back button to return to post
Well I think that about does it. Yes, let me concur with some of you who think that this might be a management nightmare, maintaining all those storage containers; but once setup it does the job and does it correctly. Until VMware provides a more viable solution for vRA 7, there are some choices.
A final comment to all our VMAX All Flash customers. You already have all the vRA 7 integration you need. As the VMAX All Flash has a single SLO (Diamond), you don’t have to go through all these steps. Simply choose the VVol datastore (like the very first example in the post) and you have vRA 7 and VVol integration with EMC VMAX All Flash.
When the next release of VVols comes about, things get more complicated because there will be more capabilities available (hint: replication) and we can’t simply create multiple storage containers. Hopefully by then VMware will have filled in the vRA gap so my post becomes irrelevant.
Dell PowerFlex and PowerMax with VMware 