During the ongoing operation of your OpenStack cloud, you will occasionally encounter trouble where a Cinder volume will get stuck in an odd state. During the course of writing this chapter, the authors had a number of volumes getting stuck in the attaching status, after an instance failed to boot from them. This looks like the following:
openstack volume list -c Name -c Status -f table
To reset the status on a Cinder volume, you will need the following:
- An
openrcfile with appropriate credentials for the environment - The
openstackcommand-line client - The
cindercommand-line client - The name or ID of the volume
For the example that follows, we will be resetting the following volumes to available:
cookbook.boot.volumecookbook.volume.boot.test
Resetting the status of a Cinder volume is done with the cinder command. Here the openstack set of commands covers most operations you will commonly need to do, and the cinder command provides additional admin functionality, such as reset-state.
To reset the status of a Cinder volume, carry out the following steps:
- First, list your Cinder volumes and statuses
openstack volume list -c Name -c Status -f tableThis will bring back a list of the volumes OpenStack knows about:
- Use the
cinderclient to reset the state of the volumes:cinder reset-state 23e1e006-a753-403c -ad8f-27e98444f71e --state available cinder reset-state e934c45f-6e2f-431f-8457-7e84f6cee876 --state available
- Confirm the new status:
openstack volume list -c Name -c Status -f tableThis will show that the state has been reset to
available:
The cinder reset-state command operates directly on the cinder database, regardless of the actual status of the volume. The --state flag we used allows us to change the status of a volume that might be stuck in a particular state. There are two additional flags that allow you to change the attachment status and migration status, respectively:
cinder help reset-state usage: cinder reset-state [--type ] [--state ] [--attach-status ] [--reset-migration-status] [ ...]
This tool explicitly updates the entity state in the cinder database. Being a database change only, this has no impact on the true state of the entity and may not match the actual state. This can render an entity unusable in the case of changing to the available state.