Skip to content

Working with 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. 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 as

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

on the instance.

Extending volumes

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

The steps are as follows

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

On the client machine (such as lxplus8), the steps for the host tim-centos7-143 and the volume timvol143 are as follows to extend the volume to 25 GB.

$ openstack volume set --size 25 timvol143

Then on the guest,

# 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.

Please 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.

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). One use case for retyping volumes is to change their IO capabilities, e.g. a change from type standard to type io1. Another use case is when you want to change where the volume is located, e.g. a change from type standard to type cp1 (from normal area to critical area)

Note: Volumes need to be detached (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 if the volume is still attached or if the retyping is not possible.