3.3 Storage Policies (SPBM) & Virtual Volumes (vVols)

3.3 Storage Policies (SPBM) & Virtual Volumes (vVols)

Traditional enterprise storage architectures rely on coarse-grained, LUN-centric management where an entire datastore is bound to static capabilities (such as RAID 10, all-flash media, or asynchronous replication). This model forces administrators to create dozens of isolated datastores and manually migrate virtual machines between them when service levels change.

Modern vSphere environments solve this operational rigidity using Storage Policy Based Management (SPBM) and Virtual Volumes (vVols), backed by vSphere APIs for Storage Awareness (VASA) and vSphere APIs for Array Integration (VAAI) hardware acceleration.

---

Storage Policy Based Management (SPBM)

Storage Policy Based Management (SPBM) is a declarative storage framework built into vCenter Server that decouples virtual machine storage requirements from physical infrastructure.

Core Architecture and Mechanics

• Rules and Rule-Sets: Storage policies consist of one or more rule-sets defining specific performance, availability, data protection, and encryption requirements.
• Storage Capabilities Matching:
  • Capability-Based Rules: Intelligent storage platforms (such as VMware vSAN and vVols) advertise their physical and logical capabilities (e.g., RAID levels, deduplication, IOPs limits, snapshots, encryption) directly to vCenter via VASA. The administrator builds policies selecting these native capabilities.
  • Tag-Based Rules: For traditional VMFS and NFS datastores that do not use VASA, administrators create vCenter tags and categories (e.g., Category: StorageTier, Tags: Gold-NVMe, Silver-SAS, DR-Replicated). The policy matches datastores based on assigned tags.
• Granular Disk-Level Assignment: A storage policy does not have to be applied uniformly across an entire virtual machine. Administrators can assign distinct policies to:
  • The VM Home Namespace (Config-vVol containing .vmx and log files).
  • Individual Virtual Disks (.vmdk): A database virtual machine can assign its operating system disk to a low-cost, deduplicated storage tier while assigning its high-transaction database write-ahead log disk to an ultra-low-latency, mirrored tier.

Compliance Monitoring Engine

SPBM continually audits the state of all managed objects against their assigned policies:

• Compliant: The underlying datastore satisfies all rules defined in the storage policy.
• Non-compliant: The storage backing the VM violates one or more rules (e.g., underlying storage replication is severed, capacity thresholds are breached, or the VM was migrated to an uncertified datastore).
• Not Applicable: The policy rules do not apply to the datastore hosting the object.
• Out of Date: The administrator edited the policy definition, but the changes have not yet been reapplied to the virtual machine.

---

vSphere APIs for Storage Awareness (VASA)

The vSphere APIs for Storage Awareness (VASA) is an out-of-band communication protocol using secure REST and SOAP APIs that bridges the gap between vCenter Server and the storage array management controller.

VASA Provider Functions

A VASA Provider (also called a Storage Provider) is software supplied by the array vendor that runs either embedded in the storage controller firmware or as a separate virtual appliance. It performs three critical duties:

1. Advertises Capabilities: Informs vCenter of underlying hardware characteristics (RAID level, encryption, deduplication, tiering, snapshot frequency).
2. Communicates Topology & Health: Alerts vCenter when array hardware components degrade, links drop, or replication links fail.
3. Facilitates vVols Lifecycle: Translates vSphere control plane commands (creating virtual disks, taking snapshots, cloning) into native array controller operations.

+-----------------------------------------------------------------------------+
|               VASA Out-of-Band Control vs. In-Band Data Path                |
+-----------------------------------------------------------------------------+
|                                                                             |
|   [ Control Plane ]                                                         |
|   vCenter Server <======= VASA API (HTTPS) =======> [ VASA Provider ]    |
|   (VM Provisioning, Snapshots, Policy Compliance)             |             |
|                                                               |             |
|   ------------------------------------------------------------|----------   |
|                                                               |             |
|   [ Data Plane ]                                              v             |
|   ESXi Host <========= Block / File Data Path =========> [ Storage Array ]  |
|   (Direct VM I/O via Protocol Endpoints: FC, iSCSI, NFS)                    |
|                                                                             |
|   * Result if VASA fails: Running VMs continue read/write I/O unimpeded.    |
|     Only control-plane tasks (create VM, snapshot, expand disk) are halted. |
+-----------------------------------------------------------------------------+

Critical Architecture Rule: Control Plane vs. Data Plane Failure

Understanding the separation of planes is a frequent exam objective:

• VASA resides strictly on the Control Plane: It does not process, inspect, or route guest VM read and write I/O.
• Impact of VASA Outage: If the VASA Provider crashes, reboots, or loses network connectivity to vCenter Server:
  • Running Virtual Machines are completely unaffected: All active VMs continue reading and writing to their virtual disks at full wire speed because data traffic traverses the physical HBAs and Protocol Endpoints directly.
  • Administrative Operations are blocked: Administrators cannot create new VMs, power on VMs, take snapshots, expand disks, or re-evaluate storage policies until VASA connectivity is restored.

---

Virtual Volumes (vVols) Architecture

Virtual Volumes (vVols) fundamentally redefines external storage integration by replacing coarse-grained LUNs with native, array-managed objects.

The Core Components of vVols

1. Virtual Volume Objects: Instead of storing multiple VM files inside a shared VMFS filesystem, the storage array natively creates distinct volume objects for each component of a VM:
   • Config-vVol: Stores configuration files (.vmx), .nvram, logs, and descriptor files (sized at ~4 GB).
   • Data-vVol: Represents a virtual disk (.vmdk), created as a native raw volume on the SAN/NAS.
   • Swap-vVol: Created dynamically when a VM powers on to hold virtual memory swap space (.vswp).
   • Memory-vVol: Stores virtual machine memory state when taking a snapshot with memory.
2. Protocol Endpoints (PE):
   • In traditional storage, an ESXi host addresses each LUN directly, quickly exhausting the ESXi limit of 1024 LUNs in dense environments.
   • In vVols, ESXi does not directly attach to thousands of individual Data-vVols. Instead, the array presents a small number of Protocol Endpoints (PEs).
   • A Protocol Endpoint is an administrative proxy device (a tiny LUN for FC/iSCSI or an export mount point for NFS). The ESXi host establishes an I/O channel to the PE, and the PE dispatches I/O to specific vVol objects using Second-Level LUN addressing (sub-LUN addressing). This completely circumvents traditional SCSI LUN allocation limits.
3. Storage Containers:
   • A logical grouping of raw physical capacity carved out on the array by the storage administrator.
   • Unlike a VMFS datastore, a Storage Container has no filesystem format; it is purely a capacity quota and capability boundary.
   • When mounted in vSphere, the Storage Container is represented in the vCenter inventory as a vVols Datastore.
4. Array-Offloaded Snapshots:
   • In traditional VMFS, taking a VM snapshot creates a redo-log delta disk (-000001.vmdk). As delta files grow, VM read performance degrades, and snapshot consolidation causes noticeable "VM stun" (temporary packet drop or paused execution).
   • In vVols, snapshots do not create ESXi redo logs. vSphere asks the array, through VASA, to create an array-native point-in-time snapshot. Deleting a snapshot is also handled by the array, which avoids the growing delta-disk chains and long consolidation work of VMFS snapshots.

---

vSphere APIs for Array Integration (VAAI)

vSphere APIs for Array Integration (VAAI) is a hardware acceleration framework that offloads storage-intensive operations from the ESXi host CPU, memory, and SAN fabric uplinks directly to the physical storage array controller.

1. Block Storage Primitives (FC, FCoE, iSCSI)

2. NAS (NFS) Storage Primitives

For NFS datastores, VAAI operates via vendor-supplied NAS plugin libraries installed on ESXi:

• Full File Clone: Offloads cold VM cloning and template deployment to native NAS snapshots.
• Fast File Clone: Enables array-level linked clones (heavily utilized in VMware Horizon virtual desktop deployments).
• Extended Stats: Allows ESXi to query space utilization on NFS shares without recursively traversing directories.
• Reserve Space: Enables creation of true thick-provisioned virtual disks on NFS datastores.

Creating a VM Storage Policy (Objective 7.4.2)

1. Go to Menu > Policies and Profiles > VM Storage Policies > Create, and name the policy.
2. Choose the policy structure:
   • Host-based services: for example encryption (VM Encryption) and Storage I/O Control components.
   • Datastore-specific rules: vSAN or vSAN ESA rules (failures to tolerate, RAID method, stripes, space reservation), vVols rules published by the array vendor, or tag-based placement rules for VMFS and NFS datastores.
3. Define the rules, then review the Storage compatibility page, which lists the datastores that satisfy the policy.
4. Apply it: choose a policy when you create or clone a VM, or use VM Policies > Edit VM Storage Policies to set it per VM home and per disk.
5. Monitor compliance. If you edit a policy, VMs show Out of Date until you Reapply it, and vSAN may resynchronize objects when you do.

Exam Trap: A tag-based rule does nothing until the datastores carry the matching tags. If no datastores appear as compatible, check the tag assignments first.