At VMworld last year, Duncan Epping and I presented on the power of Storage Policy Based Management (SPBM for short). You can find all of the slides and recordings here. One of the demos we used in the presentation was deploying virtual machines via vRealize Automation, and showing how to consume a storage policy on vSAN. This was using a vRealize Automation plugin, and to be honest, it was a little bit challenging to get it to work. And it wasn’t really a VMware plugin per-se, but something developed by our field team. Today, I’m pleased to announce that we have created a fully fledged vRealize Orchestrator plugin which has been tried and tested, and should work out of the box. During our VMworld presentation, we also talked about an upcoming provisioning product from our management business unit, called Cloud Assembly. Cloud Assembly is part of a series of SaaS offerings that provide programmable provisioning across multiple clouds. The cool thing about Cloud Assembly from a storage perspective is that you can consume the underlying storage policies without needing a plugin. Let’s take a look at both options in a bit more detail.

vRealize Automation/vRealize Orchestration plugin for Storage Automation v2.5



As mentioned in the introduction, there is now an updated plugin called vRA plugin for Storage Automation v2.5 available on VMware Solution Exchange. This plugin will allow VMs deployed via vRA blueprints to consume storage policies. While this plugin has been available in one form or another for a few years, the major change is that VMware is now providing official support for it via GSS as well as a dedicated engineering team (so long as you have an active vRA and vSAN/vSphere license).

Here is an overview of the solution:

Expose SPBM storage policies from vCenter to vRA UI (vSAN, VVols, etc)

Self-service selection of a storage policy during day 1 VM provisioning

Self-service changing of a storage policy during day 2 operations, which includes automated migrating/adjusting underlying datastore placement to a different datastore (or even across vCenter Servers).

Fully interop with vRA 7.5/7.4 as well as latest vSphere/vSAN releases

You can find more information about the new v2.5 Storage Automation plugin in this official VMware blog and there is also a demo and detailed technical guidance on StorageHub.

Cloud Assembly

Let’s talk about updates to Cloud Assembly next. I suppose the first thing to point out is that is not simply a SaaS version of vRA. It would be more precise to state that it is a ground-up build of our cloud management stack, available in SaaS. Features include:

Set of automation (SaaS) services developed as a true cloud-native application

Engineered to support modern DevOps practices and API-centric approaches

Part of VMware Cloud Services portfolio

Includes core provisioning and Lifecycle Management., Infrastructure as Code (IaC), Catalog and Pipeline

Multi-cloud use cases: On-premises VMW SDDC, VMware Cloud on AWS, AWS, Azure

Multi-platform: VMs, container services (PKS), PaaS (PCF)

As I mentioned at the beginning of the post, from a storage perspective, SPBM policies are natively exposed in Cloud Assembly and are consumable during provisioning. Cloud Assembly will discover and collect all existing SPBM policies once the vSphere provider is configured. This includes all the out-of-the-box SPBM policies – e.g. Default Storage Policy, VM Encryption, VVol No Reqs, etc. – and anything created by the user.

The policies can be tagged via Capability Tags to provide additional controls on placement. To use these policies, the VI-Admin must first create one or more Storage Profiles in Cloud Assembly, selecting the desired Storage Policy, associated datastore, and other options shown below. A Capability Tag can then be added to identify the Storage Profile by some named value (e.g. ALL-FLASH-VSAN, ENCRYPTED-VSAN).

Storage Profiles can be created for all storage types, vSAN, VMFS, NFS, as shown below:

Storage placement is declared in the blueprint’s YAML (properties -> storage -> constraints -> tag). In this case, the tag is populated by user input at provisioning time, which will result in the WebTier disk (selected in the blueprint) being placed on a datastore which matches a tag within the configured Storage Profile:

Now a common question we have had in the past is whether we have any lower granularity to select/build a policy at provisioning time, e.g. for vSAN, can we select a FailuresToTolerate value at provisioning time? At this point in time, the answer is no. The granular SPBM policies are currently not exposed for use right now. However, I am led to believe that this may change in future.

In closing, I do want to emphasize one point – the new SPBM plugin mentioned earlier is NOT a requirement for Cloud Assembly. It is only required for vRealize Automation when you wish to consume SPBM policies at provisioning time.

Kudos to my colleague and good friend Jad El-Zein for fielding a lot of my questions on this behavior. If you’re not already following Jad on twitter, please consider doing so for all the latest and greatest VMware management information.