OpenStack Cinder Volume Migration: Moving Between Backends

In the previous posts I explored how the Cinder scheduler interprets capabilities, extra_specs, and how multiple backends can intentionally share the same volume_backend_name to present a unified storage tier. That abstraction is powerful — but it also introduces an operational question: How do you move an existing volume between two backends when the scheduler treats […]

Multiple Arrays, One Backend Name: Horizontal Scaling in OpenStack Cinder

Scaling Horizontally with Multiple Arrays, One Backend Name In Part 1, I covered the fundamentals of intent-based volume types: how to use capabilities and filters to let the Cinder scheduler match workload requirements with backend characteristics. We described storage infrastructure, defined workload personas, and let the scheduler do the matching. But there’s a powerful scaling […]

OpenStack Cinder Scheduling: How to Stop Hard-Coding Storage Tiers

From Hardware Names to Workload Intent The Cinder scheduler doesn’t get much love. Most people see it as boring infrastructure plumbing. But when you lean into its design, something interesting happens: it becomes a decision engine that quietly translates intent into placement, without hard-coding tiers or baking policy into application logic. This is the first […]