Lessons From Migration: Finding the Right Way to Remove Cinder Volumes Without Data Loss

Cleaning Up Cinder Volumes Safely after Cinder-CSI → Ceph-CSI Migration

In our OKD setup, we initially consumed persistent volumes through Cinder-CSI, backed by Ceph RBD. Over time, we migrated workloads to Ceph-CSI directly. The migration was done in-place - meaning the same Ceph RBD images were re-referenced by new PVCs, without copying data across pools or clusters -

That left us with a housekeeping problem: what to do with the old Cinder volumes still tracked in the OpenStack control plane?

The challenge

When you remove a volume in Cinder, it normally:

• Deletes the record from the Cinder database, and
• Tells the backend driver (in this case, Ceph RBD) to delete the actual block device.

But in our case, the backend RBD images were still actively referenced by the new Ceph-CSI PVCs. Deleting them at the storage layer would have been catastrophic.

So we needed a way to:

• Remove the volumes from Cinder’s control plane,
• While leaving the Ceph RBD images untouched.

My first thought was to go with option 1, but I wasn’t fully confident about the risks. So I kept digging, and eventually stumbled upon option 2 - the safer path and the real focus of this write-up -

Option 1: Manual DB surgery

One way is to dive directly into the Cinder DB and mark volumes as deleted. This works but it’s also risky and error-prone. A typo or missed relationship can corrupt your state or leave orphan records. It’s the kind of thing you only want as a last resort.

Option 2: Using cinder unmanage (the supported way)

Cinder has a feature for exactly this scenario: unmanage. Instead of deleting the backend storage, Cinder simply:

• Marks the volume as deleted in its database,
• Calls the driver’s unmanage() method, which by design leaves the underlying storage object intact.

Here’s what it looked like in practice:

Before unmanage

cinder show d1ba5a94-2756-4683-8534-85917339fd65        

Status: available

DB entry: present, deleted=0

Run unmanage

cinder unmanage d1ba5a94-2756-4683-8534-85917339fd65        

After unmanage

cinder show d1ba5a94-2756-4683-8534-85917339fd65
ERROR: No volume with a name or ID of '...' exists.        

In the Cinder database:

• status flipped to deleted
• deleted=1
• deleted_at and terminated_at were populated

But crucially, the Ceph RBD image was untouched:

rbd -p okd-replica-3-standard info volume-d1ba5a94-2756-4683-8534-85917339fd65        

Still present, with the original size and features.

Digging into the code

Looking into Cinder’s source confirmed this behavior:

• The API routes os-unmanage into API.delete(unmanage_only=True)
• The manager then calls driver.unmanage(volume) instead of driver.delete_volume(volume)
• The DB record is removed, but the driver does not delete the backend object

Here’s the sequence diagram that makes the control flow clear:

Why this matters

• Safe cleanup: Keeps Ceph RBD data intact while retiring control-plane clutter.
• Audit-friendly: The DB record shows the volume as deleted, no hacks required.
• Reversible: If ever needed, the same RBD image can be re-imported back into Cinder via cinder manage.

Resources:

• Openstack codebase
• Cinder cli document
• Mermaid charts: Used for creating the diagram