Skip to content

Administering Volumes

Identifying volumes

In cases where multiple volumes are attached to the same instance, it is desirable to establish a mapping between volume IDs (in OpenStack) and the block devices inside the guest virtual machine. Volumes appear in /dev/disk/by-id as entries of the form virtio-ID where ID is a subset of the OpenStack volume ID.

For instance, a volume like

$ openstack volume list
+--------------------------------------+----------------+-----------+------+----------+
| ID                                   | Display Name   | Status    | Size | Attached |
+--------------------------------------+----------------+-----------+------+----------+
| ce16c82e-12be-40b1-a189-252c4c61514b | None           | in-use    |    5 |          |
+--------------------------------------+----------------+-----------+------+----------+

would appear in the guest instance as

$ ls /dev/disk/by-id/
virtio-ce16c82e-12be-40b1-a

Extending volumes

A volume can be made larger while maintaining the existing contents, assuming the overlaying file system supports resizing.

The steps are as follows:

  • Extend the volume to its new size
  • Extend the filesystem to its new size

For example, to extend the volume timvol143 to 25 GB attached to VM tim-centos7-143:

$ openstack volume set --size 25 timvol143

Then on the VM tim-centos7-143,

# mount /dev/vdc /mnt/timvol143
# resize2fs /dev/vdc
resize2fs 1.42.9 (28-Dec-2013)
Filesystem at /dev/vdc is mounted on /mnt/clone; on-line resizing required
old_desc_blocks = 2, new_desc_blocks = 4
The filesystem on /dev/vdc is now 6553600 blocks long.

For XFS, a similar procedure can be followed using the xfs_grow command.

For Windows systems, please follow the provider documentation.

Note:

  • Volumes can be made larger, but not smaller. There is no support for shrinking existing volumes.
  • The procedure given above has been tested with ext4 and XFS filesystems only.
  • It is advisable to unmount the filesystem and detach the volume before extending it.

Retyping volumes

The type of a volume can be changed in order to change the characteristics of an already existing volume (e.g. one that has already data stored). For example, one can change the IO capabilities of a volume, e.g. from type standard to type io1, or its availability in the event of a power cut, e.g. from standard to cp1. Volumes need to be in state 'available' to allow for retyping.

In order to retype our example volume from type standard to type cp1 the command would read:

$ openstack volume set --type cp1 --retype-policy on-demand timvol143

The parameter retype-policy is required when the retype entails a migration, i.e. a change of the area in which the volume is hosted.

In the cloud there are different areas for volumes hosted:

  • Standard area (standard, io1, io2, and io3 volume types)
  • Critical area (cp1, cpio1, cpio2, and cpio3 volume types)

This is the matrix that shows when this parameter is required (rows defines volume area in which the volume resides, and colums defines the area in which we want to retype to)

standard critical
standard required
critical required

Note: Retyping will silently fail under several circumstances:

  • If the volume is attached
  • If the volume has snapshots
  • If attempting to retype a volume of a type with Storage availability zones (i.e., standard, io1) to a new type without.

In such cases, a support ticket is needed to perform this operation.