5.3 Storage Policy-Based Management (SPBM) Framework

5.3 Storage Policy-Based Management (SPBM) Framework

In legacy virtualization environments, storage management was tightly coupled to physical hardware silos. Storage administrators carved out physical LUNs with fixed characteristics (such as RAID 10 SSD or RAID 5 SAS), and virtualization administrators manually placed virtual machines onto datastores labeled "Gold", "Silver", or "Bronze". This manual model was error-prone, prevented automated provisioning, and led to severe capacity fragmentation.

The Storage Policy-Based Management (SPBM) framework transforms storage operations by abstracting physical array capabilities into a declarative software-defined control plane. Administrators define application service-level agreements (SLAs)—such as performance, resilience, encryption, and replication—directly in software policies. vCenter Server then dynamically matches virtual machine requirements against available storage tiers.

---

The SPBM Architectural Control Plane & Storage Abstraction

SPBM operates as a centralized management service within vCenter Server. It decouples the virtual machine's storage requirements from the physical implementation of the storage hardware:

1. Granular Policy Application: VM vs. vDisk Level

A critical capability of SPBM is its granular application hierarchy. Policies can be assigned to:

• VM Home Namespace: Houses configuration files (.vmx, logs, .nvram). Typically requires low performance and standard availability.
• Individual Virtual Disks (.vmdk): Independent disks attached to the same VM can receive completely different storage policies. For example, in an enterprise database VM, the operating system disk (Hard disk 1) can be assigned a standard, low-cost capacity policy; the active database data volume (Hard disk 2) can be bound to an ultra-high-performance striped policy; and the database transaction log volume (Hard disk 3) can be assigned a policy requiring sub-second replication and live snapshots.

2. Intelligent Placement Engine

During virtual machine creation, cloning, or Storage vMotion migration, the administrator selects a VM Storage Policy. SPBM acts as an intelligent provisioning filter:

• It queries the real-time capabilities and tags of all datastores connected to the cluster.
• It evaluates whether each datastore can satisfy the specified policy rules.
• In the vSphere Client provisioning wizard, the datastore list is dynamically partitioned into Compatible and Incompatible sections. If a datastore is marked incompatible, SPBM displays the exact rule that caused the violation (e.g., "Datastore does not satisfy encryption capability"), preventing accidental misplacement.

---

Storage Providers & vSphere APIs for Storage Awareness (VASA)

To bridge the gap between software policies and physical array hardware, VMware created the vSphere APIs for Storage Awareness (VASA) framework.

1. The VASA Communication Model

A VASA Storage Provider is a software component (typically delivered as an embedded service inside the storage array controller or a hardened virtual appliance) that establishes secure, out-of-band communication with vCenter Server:

• Out-of-Band Architecture: VASA communication travels strictly across the management network over secure HTTPS/SOAP (the provider-specific HTTPS endpoint). VASA does not sit in the virtual machine data path.
• Data Path Isolation: If the VASA provider loses network connectivity or reboots, virtual machine I/O continues uninterrupted across Fibre Channel, iSCSI, or NFS. However, management-plane operations (such as provisioning new VMs, expanding disks, taking snapshots, or checking policy compliance) will fail until VASA connectivity is restored.
• Two-Way Information Exchange: The VASA provider advertises underlying array capabilities up to vCenter Server, and in return, passes SPBM policy directives down to the storage array for hardware-level execution.

2. Registering VASA Providers in vCenter

vSAN providers register automatically with vCenter. For an external array that requires registration, administrators register its vendor-supplied storage provider in the vSphere Client under vCenter Server > Configure > Storage Providers:

1. Input the provider URL (e.g., https://storage-array.corp.local:8443/vasa/version.xml).
2. Provide administrative credentials to authenticate with the storage controller.
3. Accept and trust the storage provider's SSL/TLS certificate after validating the expected identity and certificate chain.
4. In production environments, enterprise arrays present redundant, active/standby VASA provider pairs to prevent management-plane outages.

3. vSphere Virtual Volumes (vVols) Architecture

VASA is the foundational technology powering vSphere Virtual Volumes (vVols). In traditional SAN storage, the hypervisor allocates a massive, monolithic LUN and formats it with VMFS. The storage array has zero insight into individual virtual machines; it sees only a single massive block device.

vVols completely eliminates the LUN abstraction:

• VMDK as Native Array Object: Every individual virtual disk (.vmdk), snapshot, and configuration directory is instantiated as a distinct, native array-level object (Data vVol, Config vVol, Swap vVol, Snapshot vVol). The storage array directly manages snapshots, replication, and deduplication on a per-VM basis.
• Storage Containers: Rather than formatting LUNs with file systems, the storage administrator allocates raw storage capacity pools on the array known as Storage Containers. The vSphere administrator mounts a Storage Container as a vVols Datastore without partitioning or formatting.
• Protocol Endpoints (PE): Because modern arrays cannot handle thousands of individual physical SCSI LUN connections across a fabric, vVols uses Protocol Endpoints. A Protocol Endpoint is a lightweight, transparent proxy access point established on the storage fabric (via SCSI LUN, NVMe namespace, or NFS mount point). ESXi hosts communicate with the PE, which dynamically binds and routes I/O to thousands of individual vVols on demand, bypassing physical SCSI LUN limitations.

---

Tag-Based vs. Capability-Based Policy Design

SPBM policies fall into two distinct operational categories depending on the underlying datastore technology:

1. Capability-Based Policies (VASA-Driven)

Capability-based policies are utilized for modern software-defined storage architectures, specifically VMware vSAN and vSphere Virtual Volumes (vVols):

• Storage attributes are discovered automatically via the registered VASA provider.
• Rules govern physical data layout directly: Number of Failures to Tolerate (FTT), failure tolerance method (RAID-1 Mirroring vs. RAID-5/6 Erasure Coding), disk stripes, IOPS limits, thin provisioning, and replication Recovery Point Objectives (RPO).
• If an array adds hardware features (such as hardware compression), VASA dynamically updates the vCenter capability catalog without administrative intervention.

2. Tag-Based Policies (User-Defined Metadata)

Where traditional datastores do not advertise the required capabilities, tags provide administrator-defined placement metadata. To incorporate traditional datastores into the SPBM framework, administrators utilize Tag-Based Policies:

1. Create Tag Categories: In the vSphere Client, create a category (e.g., PerformanceTier, Location, BackupSLA).
2. Create Tags: Under the category, define specific tags (e.g., Platinum-NVMe, Gold-SAS, Datacenter-East).
3. Assign Tags to Datastores: Manually apply the tags to specific VMFS or NFS datastores.
4. Construct SPBM Tag Rules: In the VM Storage Policy editor, configure a rule based on tags (e.g., "Placement: Require tag PerformanceTier: Platinum-NVMe").

---

Tag-Based vs. Capability-Based Policies Comparison

---

SPBM Policy Compliance Lifecycle & Non-Disruptive Changes

Once a virtual machine is provisioned with an SPBM policy, vCenter continuously evaluates its operational compliance against the underlying datastore.

1. Understanding Policy Compliance States

In the vSphere Client, every virtual machine and virtual disk reports an SPBM compliance status:

• Compliant: The virtual machine and its virtual disks reside on storage that completely satisfies all declared policy rules and data services.
• Non-Compliant: The storage backing the VM violates one or more policy requirements. Examples include: a datastore runs out of capacity to support a reservation, a vSAN disk object suffers more drive failures than its configured FTT allows, an array replication link fails, or an administrator manually migrates a VM to an un-tagged datastore.
• Out of Date: The definition of the assigned VM Storage Policy was modified in vCenter Server, but the new policy rules have not yet been reapplied to the virtual machine. The VM continues operating under its old settings.
• Unknown or Not Applicable: Interpret the displayed status in context. Missing provider data can prevent evaluation; a policy requiring unsupported storage capabilities makes placement incompatible rather than converting NFS into vSAN.

2. Non-Disruptive Policy Edits & Remediation Workflow

A major architectural benefit of SPBM is that storage policies can be modified dynamically without virtual machine downtime or service disruption:

When a policy is updated:

1. The administrator edits the policy definition in the vSphere Client (e.g., increasing an IOPS limit from 2,000 to 5,000 IOPS, or adjusting a replication RPO from 4 hours to 15 minutes).
2. vCenter Server updates the master policy catalog. All virtual machines bound to that policy immediately transition to the Out of Date compliance status.
3. The administrator reviews the affected VMs and initiates the Reapply operation (either globally across all VMs or selectively per VM).
4. vCenter communicates with the VASA provider or the local hypervisor storage filters. The storage layer dynamically adjusts the active parameters online in the background without disconnecting the VM, pausing execution, or requiring manual data migration.

Release boundary for vVols

vVols remains a technology administrators may encounter in the 9.0 estate. Broadcom KB 401070 discontinues 9.0 vVol certifications and describes limited case-by-case 9.0 support. It is deprecated beginning with VCF/VVF 9.0; do not treat it as the strategic default for a new deployment or apply later-release availability assumptions to this 9.0 exam. Verify a migration plan and current support notices before changing production storage.

Review Takeaways

• SPBM filters placement and specifies supported storage requirements at VM/disk granularity.
• Tags are administrator-defined placement metadata; they do not reconfigure an array RAID layout.
• vSAN providers register automatically; external provider registration follows the vendor endpoint and trust procedure.
• vVols has a specific 9.0 deprecation/support boundary and must not be presented as an unrestricted new-deployment default.