“A lot of times, people don’t know what they want until you show it to them” Steve Jobs

Last night while tearing our living room apart looking for the ROKU remote (that apparently grew legs and left our house forever) my daughter asked “why don’t you just download the ROKU remote control app to your phone?” Add that to the ever-growing list of ways I have now come to depend on my phone to do life. Directions, dining, fitness, translation, sleep diagnostics, photography, and yes, even changing the channel on my TV. It reminded me of one of my favorite quotes from the late Steve Jobs “A lot of times, people don’t know what they want until you show it to them” I often think about this quote when speaking to customers about the policy-based management framework in Virtual Volumes (VVols) and Virtual SAN (vSAN), Storage Policy-Based Management (SPBM).

With the introduction of vSAN and then later with VVols, VMware radically improved its approach to storage policy-based management. We did this to address some of the key challenges we see customers encountering with their traditional approaches to storage. In this article I am going to touch on a few of these challenges and discuss how SPBM works with our VVol partners to solve them.

Automate all the things

When speaking with customers or other IT professionals the general consensus seems to be whenever possible, “automate all the the things”.  Automation is at the heart of just about any cloud implementation.  It can provide fast provisioning, resource monitoring and self-healing, capacity adjustment, and even automated billing.  Also, automation can ensure consistency, prevent errors and free-up valuable staff time to work in more innovative projects. However, depending on who you ask automation can mean very different things. Andy Troup wrote an interesting article on automation where he identifies and defines three types of automation.

  1. Script – programs written for a special runtime environment that can interpret and automate the execution of tasks which could alternatively be executed one-by-one by a human operator. (http://en.wikipedia.org/wiki/Script_(computing))
  2. Orchestration – describes the automated arrangement, coordination, and management of complex computer systems, middleware, and services. (http://en.wikipedia.org/wiki/Orchestration_(computing))
  3. Policy – Policy-based management is an administrative approach that is used to simplify the management of a given endeavor by establishing policies to deal with situations that are likely to occur. (http://whatis.techtarget.com/definition/policy-based-management)



This image shows the frequency with which each of these types of automation should be used.  As you can see, we should be aiming for as much policy implementation as possible with as little scripting as we can achieve. In short, whenever possible implement a policy.  If you can’t implement a policy, consider orchestration and use scripting as a last resort. Fortunately, VMware customers have the benefit of automated policy-based provisioning and management using Storage Policy-Based Management (SPBM).  Read the following article for a comprehensive overview on SPBM

Storage Policy Based Management (SPBM)

Storage Policy Based Management (SPBM) is a storage policy framework that provides a single unified control plane across a broad range of data services and storage solutions. The framework helps to align storage with application demands of your virtual machines.

SPBM enables the following mechanisms:

  • Advertisement of storage capabilities and data services that storage arrays and other entities, such as I/O filters, offer.
  • Bidirectional communications between ESXi and vCenter Server on one side, and storage arrays and entities on the other.
  • Virtual machine provisioning based on VM storage policies.

Administrators build policies by selecting the desired capabilities of the underlying storage array. The SPBM engine interprets the storage requirements of individual applications specified in policies associated with individual VMs and dynamically composes the storage service placing the VM on the right storage tier, allocating capacity, and instantiating the necessary data services (snapshots, replication, etc.). The available capabilities vary by storage vendor. Be sure to check with your storage vendor for details on what capabilities are available in their VVols implementation.

Let’s take a look at a few examples of how SPBM optimizes all aspects of storage management.



Provisioning Scenario

We can use a common provisioning scenario involving a Windows VM that is running an intensive 700GB database backed by a hybrid array. The operating system and user data have been separated onto their own individual VMDKs as per VMware’s recommended practice.

This image displays the traditional provisioning approach with both VMDKs housed by the same datastore backed by high performance media. This approach is fully functional and we have provisioned this way for years. Could we do better though?

In our example, it is only our database that is requiring the extra performance from the array. In comparison to our database, the operating system’s workload is very minor and would operate well within our performance SLAs on spinning disk. If we could relocate our operating system to a spinning disk tier, while leaving the database on all-flash, we would be able to reclaim 100GB of SSD capacity.



Using Storage Policy-Based Management we can create policies that assign detailed storage characteristics to individual disks.  In this image there is only one datastore managing all disks in the array.  The Silver policy which is “HDD only” is assigned to the operating system and the Gold policy which is “SSD only” is assigned to the database. This is great incentive to examine the rest of the environment for similar opportunities for optimization.

Keep in mind there are many different storage capabilities that can be defined in VM storage policies (i.e disk type, encryption, compression deduplication, snapshots, replication, and more). For VVols, each storage vendor determines which capabilities they surface up to SPBM via their VASA Provider.

Operational Scenario

VM Storage Policies can easily be changed and/or reassigned if application requirements change. These changes are performed with no downtime and without the need to migrate (Storage vMotion) virtual machines from one LUN or volume to another. This approach makes it possible to assign and modify service levels based on specific application needs even though the virtual machines reside on the same datastore.

SDRS is SPBM Aware

In the past when you had different tiers of datastores as part of the same datastore Cluster then SDRS could potentially move a VM which was assigned policy “gold” to a datastore which was associated with a “silver” policy. Now, with vSphere 6 and forward, SDRS is aware of storage policies in SPBM and will only move VMs to a datastore that can satisfy the requirements of the VM’s storage policy.

SPBM integration with vRealize Automation

During the VMworld 2016 keynote VMware announced integrating the SPBM consumption model into vRealize Automation.  This solution exposes vSphere VM Storage policies to the vRealize Automation service catalog allowing the ability to dynamically assign individual VM storage polcies to virtual disks based on their storage requirements characteristics (performance, availability, security, etc). More on this in a future post.


Storage Policy Based Management is the foundation of the SDS Control Plane and enables vSphere administrators to over come upfront storage provisioning challenges, such as capacity planning, differentiated service levels and managing capacity headroom. Through defining standard storage Profiles, SPBM optimizes the virtual machine provisioning process by provisioning datastores at scale and eliminating the need to provision virtual machines on a case-by-case basis. PowerCLI, VMware vRealize Suite, vSphere API, Open Stack and other applications can leverage the vSphere Storage Policy Based Management API to automate storage management operations for the Software-Defined Storage infrastructure.


10 comments have been added so far

  1. For vVols specifically, I really wish SDRS could be implemented on top of it. Then I wouldn’t even need to pick which SAN’s vVol my VM get’s deployed to. SDRS would simply manage the VM based on affinity rules, latency and capacity. It would totally complete the whole picture of having a fully automated solution.

  2. I think Eric’s issue is that VVOL currently cannot span multiple arrays/vendors.
    The VVOL datastores only show as compliant or non compliant. It doesn’t consider the things Eric brought up.

  3. Hi Pete, I’m wondering if you can elaborate a little on SDRS operating with SPBM.
    In 6.5U1, I’ve created an SDRS-enabled Datastore Cluster with a mix of “Gold” and “Silver” tagged Datastores.
    However, the SPBM compatibility report reports “Gold” or “Silver” tagged policy is incompatible with all storage until I’ve removed tagged Datastores from the Cluster. I’ve also tried applying the tags to the Datastore Cluster, both the Cluster and Datastore levels, but the results are the same.

    In fact, the only way that Datastores under a Datastore Cluster appear as “Compatible” in SPBM is if ALL of the Datastores in the Cluster have the compliant policy assigned.

    If this worked as you describe, it would be awesome. I was under the impression that it was not advisable to create a Datastore Cluster with a mix of Datastores with grossly different IO capabilities.

  4. Hey Matt,

    Excellent question. Storage compatibility of a policy against the entire datastore cluster is rather conservative. The entire cluster is reported compatible only when all the datastores are compatible with the storage policy. Nevertheless, before moving a VM workload to a different datastore, SDRS checks the compatibility of the VM’s policy against the target datastore – and not the entire cluster. So in a datastore cluster with a mix of differently tagged datastores, the VM will only be moved by SDRS to those datastores that are compatible with the VM’s policy. Make sense?

  5. Taliz, Eric perhaps this limitation of not spanning on multiple arrays is no longer a limitation if you are using DataCore SANsymphony as your array. That piece of software is able to manage different arrays from different vendors in its pool and provide VVOL capabilities.

Leave a Reply

Your email address will not be published.