OpenStack Volume Deletion Fails
Encountering issues deleting volumes in Platform9 Managed OpenStack? This guide outlines the common causes for deletion failures, including migration and detachment issues, along with step-by-step res
Problem
Deletion of the volume fails with the following error in /var/log/pf9/cindervolume-base.log.
Delete for volume [VOLUME-ID] failed: Invalid volume: Volume status must be available or error or error_restoring or error_extending or error_managing and must not be migrating, attached, belong to a group, have snapshots or be disassociated from snapshots after volume transfer.
(HTTP 400) (Request-ID: [REQUEST-ID]) ERROR: Unable to delete any of the specified volumes.Environment
Platform9 Managed OpenStack - v3.6.0 and Higher
Cinder
Cause
In both these cases mentioned below, Cinder restricts the volume deletion.
Case 1: The volume stuck during volume migration.
Case 2: The volume was not cleanly detached during VM deletion.
Diagnosis
Case 1:
Volume details
Cinder volume base logs
Case 2:
Volume details
Cinder volume base logs
Resolution
Case 1: For volume stuck with migration and attach-related flags:
Set the state of the volume to "available".
Reset the migration status of the volume.
Set the attach status to "detached".
Delete the volume.
Case 2: For volumes stuck in deleting state:
Reset the state of the volume to "available"
Delete the volume
Validation
Case 1: After applying fix for volume with migration and attach metadata:
Volume status changes from deleting to available after the reset-state command.
migration_status becomes None.
attached_mode or properties like attached_mode='rw' are no longer blocking deletion.
The volume is successfully deleted from the system and no longer appears in CLI or UI.
Verify volume state:
Case 2: After applying fix for volume with migration and attach metadata:
Volume status changes from deleting to available after the reset-state command.
The volume is successfully deleted from the system and no longer appears in CLI or UI.
Verify volume state:
Additional Information
Always confirm that the volume is not in use or attached to a running instance before forcibly resetting its state.
Resetting states bypasses safety checks and should only be used when metadata inconsistencies block clean-up.
Last updated
