For the complete documentation index, see llms.txt. This page is also available as Markdown.

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:

Note

To run cinder commands, install python-cinderclient==9.4.0 Generally cinder binary is available only on the Platform9 Management Plane and Block Storage hosts directly.

  • 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