Skip to main content
Pure Technical Services

Tanzu User Guide: Storage Policy Based Management (SPBM) with vVols

Currently viewing public documentation. Please login to access the full scope of documentation.

Storage Policy Based Management (SPBM) is a highly customizable framework within vCenter that enables users to have virtual machines, containers and persisent volumes used with containers automatically placed on a desired storage resource via policy.  Effectively, it can be considered a storage abstraction layer that enables placement of data based upon what features and/or performance that you want the storage layer to include or exclude.  This stands as a significant improvement over the traditional method of selecting an individual datastore or multiple datastores depending on use case.  Examples can include:  how often or if you want a snapshot or replication policy associated with the volume, what array to use or even performance-based placement to list just a few.  By abstracting the storage layer in such a manner, both VMware administrators and their users unchain themselves from having to map a volume or persistent volume claim to the underlying array and can instead focus on placement based upon the storage SLA they need for that particular workload.  

For Kubernetes with VMware in particular, the usage of SPBM is required as persistent volume claims, storage classes and other key constructs directly reference SPBM policies by name in YAML file deployment specifications, image registries and during the Workload Management enablement procedure within vCenter.

A prerequisite for this article is to create a vVols datastore on the target vCenter.  Setting up vVols on the FlashArray with the vSphere Plugin is straight forward and easily accomplished.  The procedure to register VASA can be found at this link and how to mount a vVols datastore can be found here.

VMware vVols differ from VMFS from an SPBM perspective.  vVols can import storage information and capabilities directly from the underlying FlashArray that can be used with SPBM, while VMFS relies solely upon user-generated categories and tags built within vSphere.  This additional functionality for vVols with SPBM is advantageous in numerous ways as users can directly map policy to storage and have that policy update dynamically if anything is changed.  The first section below will provide a simple example of how this works.

Creating an SPBM Policy for vVols

To get started, click on the main vSphere menu and pick Policies and Profiles.

spbm9a.jpg

Select the 2nd option down, VM Storage Policies and then Create VM Storage Policy.

spbm10.jpg

In the spawned wizard, first select the vCenter server you want to use (if using Linked-Mode) and then provide a Name for the SPBM policy.

spbmvvols7.jpg

A key differentiator for using vVols with SPBM instead of VMFS is that vVols enables directly imports information and available capabilities from the underlying FlashArray which can then be included or excluded for a given policy.  To use this, select the Enable rules for "com.purestorage.story.policy" storage option and then click Next.

spbmvvols1.jpg

Probably the simplest rule to implement is to only allow VMs and persistent volumes using this policy to be placed on a FlashArray.  This is shown in the below Placement tab example.  An optional additional rule can be added here to use a specific FlashArray registered against the vCenter instance with the Pure Storage vSphere plugin.

vvols-spbm5.jpg

 

Under the Replication tab we can see that there are a multitude of rules that can be used to craft a policy specific to features like whether replication is enabled, replication interval as well as local snapshot Protection Groups on the FlashArray.  Multiple rules can be added by using the Add Rule button.

vvols-spbm6.jpg

Lastly if a vVol datastore has a tag assigned to it from vCenter as shown in the next section of this KB, tag-based placement rules can be setup by selecting the Tags tab and selecting the appropriate tag.  Note that using Tags is completely optional for building SPBM with vVols.

spbmvvols3.jpg

In the below example we can see that a single vVol datastore meets the criteria we set in the previous steps.  If this is as desired, click on the Next button, if it is not then adjust the policy rules accordingly from the previous step.

spbmvvols4.jpg

Review and select Finish to create the SPBM policy.

spbmvvols5.jpg

As mentioned earlier, a vVol datastore can optionally be tagged within vCenter via the following procedure if using vCenter-based tagging is desired.  This next section will cover how create a vSphere Category and Tag first below.

Creating Categories and Tags in vSphere for vVols (Optional)

Using vSphere-based tagging and categories is optional, but is extremely useful to capture user generated values and conditions that the FlashArray has no knowledge of.  A good example is using categories to delineate between certain departments or groups within the business.  Of key importance, though, is that vSphere-based tagging does not update dynamically like it does for array-based tagging - meaning that users need to be diligent in ensuring that the policies that they create remain accurate.

First, enter the Tags and Custom Attributes menu within the vSphere client.

spbm1.jpg

Next, select the Categories  button and then New.

spbm2.jpg

Choose a descriptive Category Name, select One Tag and lastly pick Datastore and Datastore Cluster as the Object Types.  Click OK to finish creating the new category. 

vvols-spbm1.jpg

In similar fashion as with the Category we just created, next we will add a Tag to that Category.  Select the Tags option this time and then NEW.

tag1.jpg

In the Add Tag wizard, provide a descriptive Name, select the Category created in the previous step and then click OK.

vvols-spbm2.jpg

 

 

Next, right-click on the vVols datastore you want to use for Workload Management, select Tags & Custom Attributes then Assign Tag...

vvols-spbm3.jpg

Pick the appropriate Tag you want to use and click on Assign.

vvols-spbm4.jpg