SolidFire customers and partners have direct access to various tools through our GitHub repositories. Recently I released a PowerShell module designed to help customers who are interested in leveraging Storage Policy Based Management (SPBM) to do so dynamically. The SolidFire-SPBM module includes functions that leverage SolidFire PowerShell Tools and PowerCLI to create tags and policies that administrators and consumers can leverage when deploying and managing datastores in vSphere. The most exciting part about this integration is that those tags and policies are generated dynamically based on the characteristics of the SolidFire volume supporting a VMFS datastore.

What is SPBM?

SPBM is VMware vSphere’s Storage Policy Based Management. This is a framework that allows administrators to create policies that represent the capabilities of their storage infrastructure.

There are a variety of use cases for SPBM, many of which are only recently being fully realized with the newly released VMware Virtual Volumes (VVols). Traditionally, administrators could only assign policies in a limited capacity, often providing policies representing different performance tiers across multiple storage platforms. Today, policies can be created to assist in maintaining compliance or SLAs. Organizations can create policies, for example, that represent datastores that are backed by replication or encryption features. These policies can be used to audit and ensure applications reside on appropriate storage based on more granular service requirements.


One thing you’ll note is that the workflow made possible with this integration is very similar to the management workflow you would expect leveraging VMware Virtual Volumes (VVols). SPBM is a core component of the VVols feature and will likely serve as the biggest operational disruption of implementation. It will also provide the widest range of benefit to both consumers and administrators alike.


How did you integrate?

In order to accomplish this, I leveraged a little known and utilized feature of SolidFire objects called attributes. These key-value pairs can be associated with objects like volumes and accounts on a SolidFire system. The module makes it easy for administrators to assign workload attributes to each volume based on their categorization of the volume and its performance profile. Those attributes are then leveraged alongside the performance profile to create the tags and policies needed for SPBM.


For example, let’s say a volume has a Quality of Service (QoS) profile of 1,000 min, 2,000 max, and 3,000 burst IOPs, and we want to categorize that as a Standard workload for standard OS disks. Functions are provided that allow an administrator to create a vSphere tag that matches the workload attribute: Standard. Another function is available to assign tags to datastores based on that attribute and available tags. These are a few of the incremental steps. The real workhorse is the New-SPBMPolicyFromDatastore, which will handle all tasks end to end for creating and assigning a policy to a datastore.

The current SolidFire-SPBM function contains nine functions, all of which can be used independently when needed.

What about …?

These functions do not account for all of the various use cases and conditions that often challenge administrators leveraging shared VMFS datastores. I have provided all of the core fundamentals that would allow an organization to accelerate their implementation of SPBM. It would not be very challenging to apply additional logic to the functions, in order to: 1. identify performance multipliers based on number of disks anticipated per VMFS datastore or 2. leverage multiple attributes to define the tags and policies needed. I will likely make improvements myself, but I am more than happy to review any pull requests if someone would like to contribute.

You can access the code and make contributions on GitHub. Post questions and join the conversation in the SolidFire Developer’s Community.

What’s Next?

In upcoming commits, you’ll have the ability to deploy new datastores based on the policy and characteristics of an existing datastore. This can enable dynamic provisioning and allow organizations to create scheduled tasks or alerts that could initiate the creation of new datastores programmatically. Also consider the incredibly valuable opportunity to allow consumers and administrators to request a policy change and have the management framework change, instead of relying on potentially impactful storage vMotions. More on that in a future post.

I’m always open to your questions and thoughts. Thanks for reading!

Josh Atwell

Josh Atwell is a Cloud Architect for SolidFire focusing on developing VMware and automation solutions. Over the last 10+ years he has worked very hard to allow little pieces of code to do his work for him through various automation tools. Most recently Josh worked as a vArchitect for VCE where he worked with customers to architect solutions to meet their infrastructure needs. He also served as a VMware and cloud champion, as well as being selected as a technical team lead. Prior to VCE Josh worked at Cisco on the Virtualization Infrastructure Operations team where he focused on automation for VMware, Cisco UCS, and architecting Splunk for all of IT. Josh is a contributing author to the popular Mastering vSphere series and the upcoming Devops for VMware Administrator book. He is highly involved in the virtualization community where he's been active leading technology based user groups and the vBrownBag podcast. Josh holds a degree in aerospace engineering from North Carolina State University and has maintained residence in the Raleigh, NC area.

1 comment