A volume reports two independent fields: status describes the volume itself, and modificationStatus describes the last resize. Creating, importing, resizing, and deleting a volume are asynchronous. The request returns as soon as the platform accepts it, and these fields tell you how the work ended.
Status
The following diagram shows the status values and what moves a volume between them.
| Status | Meaning | Billed | Counts against quota |
|---|---|---|---|
CREATING | The platform is provisioning the volume. | No | Yes |
AVAILABLE | The volume exists and isn’t attached to an instance. | Yes | Yes |
INUSE | The volume is attached to an instance. claimRef names the attachment. | Yes | Yes |
DELETING | The platform is removing the volume. | No | Yes |
DELETED | The volume is gone. | No | No |
ERROR | Creating or deleting the volume failed. statusReason says what failed. | No | Yes |
An INUSE volume moves to DELETING only when the instance it’s attached to is terminated and the volume is set to be deleted with it. A delete you request yourself is refused while the volume is attached. See Delete a volume.
To see which instance holds an INUSE volume, see Find the instance a volume is attached to.
When an operation fails
A failed operation never reports success. The volume tells you what happened:
- A volume that couldn’t be created ends in
ERRORinstead ofAVAILABLE. It has no usable disk behind it. Delete it and create a new one. - A volume that couldn’t be deleted stays in your volume list as
ERRORinstead of reachingDELETED. Its disk may still exist, so it still counts against your quota. Delete it again once the cause is resolved.
statusReason is null for every status except ERROR. When set, it has the form the operation failed (<code>), for example the operation failed (ERR_IMPORT). For the codes an import can report, see Import a disk image as a volume.
Requests the platform can tell are invalid up front, such as deleting an attached volume or shrinking a volume, are refused immediately with an error. They never reach ERROR, and nothing about the volume changes.
Modification status
The following diagram shows how modificationStatus tracks a resize.
| Value | Meaning |
|---|---|
COMPLETED | No resize is in progress. The last resize, if any, was applied. |
RESIZING | A resize is in progress. pendingSizeInGib shows the target size. |
FAILED | The last resize wasn’t applied. modificationStatusReason says why. |
MODIFYING | A modification is in progress on a volume that reports no target size. Treat it like RESIZING. |
sizeInGib changes only after the platform confirms the new size, so it’s always a size the disk really has. While a resize runs, compare sizeInGib with pendingSizeInGib to tell “still in progress” from “didn’t happen”. A failed resize leaves the volume’s data and sizeInGib untouched. For details, see Resize a volume.
Settled states
A state that has settled stays settled. Only something you do next changes it:
- A
DELETEDvolume never reappears in your list and never returns toERROR. - An
ERRORvolume leaves that state only through another delete. - A
FAILEDresize keeps itsmodificationStatusReasonuntil you request another resize.
Deleted volumes
A deleted volume drops out of your volume list immediately. You can still look it up by its URN with origin storage get-volume or the pvs.volume query, with no time limit, and it reports DELETED.
A volume that outlived its instance
When you terminate an instance, the volumes created with it are normally deleted too. If one of them can’t be deleted, most often because a snapshot of it still exists, the platform keeps the volume instead of failing the termination. The volume is AVAILABLE, it’s yours, and it’s billed.
retentionNote on the volume explains why it was kept. It’s null on every other volume, including volumes you created yourself. To remove a kept volume, delete its snapshots and then the volume. See Delete a volume.