> For the complete documentation index, see [llms.txt](https://docs.platform9.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.platform9.com/private-cloud-director/storage/block-storage/storage-scheduler-and-pools.md).

# Storage Scheduler and Storage Pools

## Overview

When you request a block storage volume in <code class="expression">space.vars.product\_name</code>, 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](/private-cloud-director/storage/volume.md) article does not cover: **storage pools** and the **storage scheduler**.

{% hint style="info" %}
**Read the data model first.** This page builds on the concepts introduced in the [Volume](/private-cloud-director/storage/volume.md) 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.
{% endhint %}

## Where This Fits in the Storage Model

The [Volume](/private-cloud-director/storage/volume.md) 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](/private-cloud-director/storage/volume.md) article | The class of storage a user selects; its properties tell the scheduler what is required.                                              |
| **Volume backend** / **volume backend configuration** | [Volume](/private-cloud-director/storage/volume.md) 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.                                                                  |

{% hint style="info" %}
**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.
{% endhint %}

## 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](/private-cloud-director/storage/volume.md) 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](/private-cloud-director/storage/volume.md) 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](/private-cloud-director/storage/troubleshooting-and-log-files/backend-selection-and-tuning.md).
* For per-backend configuration examples, see [Certified Block Storage Drivers & Configurations](/private-cloud-director/storage/block-storage/volume-backend-configuration-examples.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.platform9.com/private-cloud-director/storage/block-storage/storage-scheduler-and-pools.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.