Storage Scheduler and Storage Pools

Overview

When you request a block storage volume in Private Cloud Director, you do not choose a specific disk on a specific array. Instead, you select a volume type, and the Persistent Storage Service decides where the volume is physically created. This page explains the part of that decision that the Volume article does not cover: storage pools and the storage scheduler.

Read the data model first. This page builds on the concepts introduced in the Volume article — volume type, volume backend, and volume backend configuration. If those terms are new, read that article first. This page adds the final hop in that model: the storage pool a volume lands on, and the scheduler that chooses it.

Where This Fits in the Storage Model

The Volume article describes how a volume request is routed:

volume type → volume backend → volume backend configuration

This page extends that chain with one more hop — the storage pool — and explains the scheduler that walks the chain:

volume type → volume backend → volume backend configuration → storage pool

Concept	Where it is defined	Role in placement
Volume type	Volume article	The class of storage a user selects; its properties tell the scheduler what is required.
Volume backend / volume backend configuration	Volume article	The logical backend and its driver-level connection(s) to a storage array.
Storage pool	This page	A unit of capacity within the array reached by a volume backend configuration. The scheduler places each volume on a specific pool.
Storage scheduler	This page	The management-plane component that selects a pool for every volume.

Both deployment models. The storage scheduler runs in the management plane. In SaaS deployments Platform9 operates the management plane (and therefore the scheduler) for you; in Self-Hosted deployments you operate it on-premise. The concepts on this page apply to both models.

Storage Pools

A storage pool is a unit of capacity, within the storage array reached by a volume backend configuration, that the scheduler treats as a single placement target. A pool is the level at which capacity and capabilities are reported and at which volumes are placed.

How a backend maps to pools depends on the storage technology:

• An NFS backend typically exposes each NFS share as a separate pool. A backend with four shares presents four pools, each with its own free and total capacity.

• A block (FC / iSCSI) backend commonly exposes a single pool that represents the array (or a storage group within it).

• Some arrays expose multiple pools that map to tiers or aggregates on the array.

This distinction matters for capacity planning: the scheduler tracks free space per pool, not per backend. A volume backend can have plenty of total capacity yet still fail to place a volume if the specific pool the request targets is full.

The Storage Scheduler

The storage scheduler chooses a pool for every new volume (and for migrations and retypes). When a volume type maps to more than one volume backend configuration — for example, several hosts serving the same volume backend for high availability, or a backend exposing several pools — the scheduler decides which pool ultimately receives the volume. It works in three conceptual stages:

1. Gather pool state. Every block storage host periodically reports the state of each pool it manages — free and total capacity, and which capabilities it supports (thin provisioning, multiattach, QoS, and so on). The scheduler caches these reports.

2. Filter. The scheduler eliminates pools that cannot satisfy the request — for example, pools without enough free capacity, or pools that lack a capability the volume type requires.

3. Weigh and select. Among the pools that pass filtering, the scheduler ranks the survivors and places the volume on the best one. By default it favors the pool with the most free capacity, which spreads volumes across pools to balance utilization.

If no pool passes the filters, the volume create fails with No valid host was found.

How a Volume Request Flows End to End

Bringing the full model together, a volume create flows like this:

1. A user requests a volume and selects a volume type.

2. The volume type maps to one or more volume backends, each realized by one or more volume backend configurations on block storage hosts (see the Volume article).

3. The scheduler reads the volume type's requirements, filters the storage pools offered by those volume backend configurations to the ones that qualify, and weighs the survivors.

4. The winning pool is on a particular volume backend configuration, managed by a particular block storage host.

5. That host issues the provisioning command to the storage array, and the volume becomes available.

Next Steps

• For the volume type, volume backend, and volume backend configuration model this page builds on, see the Volume article.

• To diagnose placement problems — a volume on the wrong backend, stale capacity, or No valid host was found — see Persistent Storage Service Backend Selection and Tuning.

• For per-backend configuration examples, see Certified Block Storage Drivers & Configurations.