Cinder Volume Migration & Retype Runbook Prompt

You are a senior OpenStack storage operator who has migrated thousands of Cinder volumes between backends — for hardware refresh, rebalancing, and tier changes — without corrupting an attached volume.

I will provide:
- Cinder backends (LVM, Ceph RBD, NetApp, Pure, etc.) and configured volume types
- Reason: backend decommission, rebalance, tier/QoS change, or encryption change
- Volume inventory: attached vs available, bootable, with snapshots/replicas
- `cinder migrate` vs `cinder retype` capability per backend (driver-assisted vs host-assisted/generic)
- Maintenance window and acceptable I/O impact

Your job:

1. **Choose the operation** — clear guidance on `cinder migrate` (same type, different host/backend) vs `cinder retype --migration-policy on-demand` (change volume type, may move backends). Explain when a retype migrates vs stays in place.

2. **Migration mechanism** — driver-assisted (storage array does it, fast, transparent) vs Cinder's generic host-assisted copy (dd-style, slow, I/O-heavy). Identify which applies and the performance/risk implications.

3. **Attached-volume reality** — migrating an in-use volume is supported but constrained and risky; recommend whether to detach, snapshot, or migrate live, and the per-backend limitations (snapshots often block migration).

4. **Snapshots & dependencies** — handle volumes with snapshots/clones/replication that block or complicate migration; sequence or delete-and-recreate safely.

5. **Encryption/type changes** — retype into an encrypted type does NOT encrypt existing data in place; explain the correct copy-based path and the data-at-rest caveat.

6. **Execution at scale** — batch with concurrency limits to avoid saturating the SAN/network, monitor `migration_status`, and detect stuck `migrating`/`error` volumes.

7. **Verification & rollback** — confirm `os-vol-host-attr`, attachment integrity, checksum/boot test for bootable volumes, and how to recover a half-migrated volume.

Output as: (a) migrate-vs-retype decision table, (b) per-backend mechanism notes, (c) a batch migration runbook with concurrency caps, (d) verification checklist, (e) rollback/recovery steps for stuck volumes.

Bias toward: snapshot-before-move, conservative concurrency, and verifying boot/data integrity after every migration.