/cinder

name: openstack-cinder
description: "OpenStack Cinder block storage service. Provides persistent volume management for cloud instances including volume creation, snapshots, backups, LVM/iSCSI backend, volume types with QoS, encryption (LUKS), volume migration, and multi-backend support. Use for deploying, configuring, operating, and troubleshooting OpenStack block storage."
user-invocable: true
allowed-tools: Read Grep Glob
metadata:
  extensions:
    gsd-skill-creator:
      version: 1
      createdAt: "2026-02-23"
      triggers:
        intents:
          - "cinder"
          - "volume"
          - "block storage"
          - "snapshot"
          - "backup"
          - "LVM"
          - "iSCSI"
          - "volume type"
          - "storage backend"
        contexts:
          - "deploying openstack storage"
          - "managing volumes"
          - "troubleshooting storage"
          - "configuring storage backends"

OpenStack Cinder -- Block Storage Service

Cinder provides persistent block storage volumes that attach to Nova compute instances. Unlike ephemeral storage (which disappears when an instance is deleted), Cinder volumes persist independently of the instance lifecycle. They can be detached from one instance and reattached to another, snapshotted for point-in-time copies, and backed up for disaster recovery.

Architecture

Cinder uses a **backend driver architecture** that abstracts the underlying storage technology. The storage backend handles the actual block device operations while Cinder provides a uniform API.

• **LVM/iSCSI backend:** The default for single-node deployments. Cinder creates logical volumes in an LVM volume group and exports them over iSCSI to the compute host. Simple, well-understood, and requires no external storage infrastructure.
• **Ceph (RBD) backend:** The standard for multi-node production deployments. Cinder creates RBD images in a Ceph pool. Provides replication, snapshots, and thin provisioning natively.
• **NFS backend:** Mounts NFS shares and creates volume files on them. Useful for environments with existing NFS infrastructure.

**Service components:**

• `cinder-api`: Receives REST API requests and routes them to the scheduler.
• `cinder-scheduler`: Selects the appropriate backend and volume node for each operation using configurable filters and weighers.
• `cinder-volume`: Manages the actual volume lifecycle on the backend. One instance per backend.
• `cinder-backup`: Handles volume backup and restore operations to a backup target (Swift, NFS, Ceph).

Deploy

Kolla-Ansible Configuration

Key settings in `globals.yml`:

# Enable Cinder
enable_cinder: "yes"

# Enable backup service (optional but recommended)
enable_cinder_backup: "yes"

# LVM backend configuration
cinder_volume_group: "cinder-volumes"

# Backup target (Swift is the default when Swift is enabled)
# cinder_backup_driver: "swift"
# cinder_backup_driver: "nfs"

LVM Volume Group Setup

Before deploying Cinder with the LVM backend, create the volume group:

# Identify available disk or partition (e.g., /dev/sdb)
lsblk

# Create a physical volume
pvcreate /dev/sdb

# Create the volume group (name must match cinder_volume_group)
vgcreate cinder-volumes /dev/sdb

# Verify
vgs
# Should show cinder-volumes with available space

If using a loop device for testing (not recommended for production):

# Create a backing file
dd if=/dev/zero of=/var/lib/cinder/cinder-volumes.img bs=1M count=20480
losetup /dev/loop0 /var/lib/cinder/cinder-volumes.img
pvcreate /dev/loop0
vgcreate cinder-volumes /dev/loop0

Container Verification

# List Cinder containers
docker ps --format '{{.Names}}' | grep cinder

# Expected containers:
# cinder_api, cinder_scheduler, cinder_volume, cinder_backup (if enabled)

# Check volume service status
openstack volume service list
# All services should show "up" and "enabled"

Configure

Volume Types and Extra Specs

Volume types define storage classes with specific capabilities. Extra specs control backend behavior.

# Create a volume type for the LVM backend
openstack volume type create lvm-standard
openstack volume type set lvm-standard --property volume_backend_name=lvm-1

# Create a high-performance type with IOPS limits
openstack volume type create lvm-performance
openstack volume type set lvm-performance \
  --property volume_backend_name=lvm-1 \
  --property provisioning:type=thick

# Set default volume type
openstack volume type set lvm-standard --property is_default=true

QoS Policies

# Create a QoS spec
openstack volume qos create standard-qos \
  --consumer front-end \
  --property read_iops_sec=1000 \
  --property write_iops_sec=500 \
  --property total_bytes_sec=104857600

# Associate QoS with a volume type
openstack volume qos associate standard-qos lvm-standard

Volume Encryption

Cinder supports volume encryption using LUKS (dm-crypt). Requires Nova to have the `os-brick` encryption connector configured.

# Create an encryption type for a volume type
openstack volume type create encrypted-volumes
openstack volume type set encrypted-volumes --encryption-provider luks \
  --encryption-cipher aes-xts-plain64 \
  --encryption-key-size 256 \
  --encryption-control-location front-end

**Note:** Volume encryption requires Barbican (key management) or a static key in `cinder.conf`. For single-node lab deployments, a static key is simpler but less secure.

Backend Configuration

The LVM backend is configured through Kolla-Ansible's `cinder-volume.conf` override:

[lvm-1]
volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver
volume_group = cinder-volumes
volume_backend_name = lvm-1
target_protocol = iscsi
target_helper = lioadm

Oversubscription Ratios

Control how much virtual capacity Cinder can allocate beyond physical capacity:

# In cinder.conf or volume backend section
max_over_subscription_ratio =