Skip to content

Creating Block Volumes

Volumes are persistent virtualized block devices independent of any particular instance. Volumes can be attached to a single instance at a time (i.e. not like a distributed filesystem such as AFS or DFS), but may be detached or reattached to a different instance while retaining all data, much like a USB drive. Volumes are stored on redundant storage and are therefore more resilient against single hardware failures.

In addition to the system disk, you can define additional volumes to be attached to a virtual machine. This is useful if you need more space than is provided on the initial flavor and gives additional flexilibity allowing for moving volumes between virtual machines, changing the quality of service (bandwidth and IOps), taking snapshots for upgrade testing and rollback, and making backups of the stored data.

The steps to create and use a block volume are:

  1. Define a disk volume of the required size (10GB in example below) and type (standard is the default type), with the desired volume name (timvol143 in the example below)
  2. Check that the volume is available for mounting using openstack volume list
  3. Attach the volume to the instance that you would like it to be available on
  4. Log in to the instance and format/mount as required

Available volume types

The volume type describes the type of storage that is being requested.

The following storage types are currently available.

Storage Type Description Datacentre Location Maximum Performance
standard The 'standard' volume type provides a reliable store which is tolerant to at least one disk failure without user impact or data loss. This is the default. Meyrin Main room / Vault * 80MB/s and 100 IO operations (both, read and write)
io1 The 'io1' volume type provides the same reliability level as 'standard' volumes, but is meant for applications with higher IO demands. Meyrin Main room / Vault * 120MB/s and 500 IO operations (both, read and write)
io2 The 'io2' volume type provides the same reliability level as 'standard' volumes, but is meant for applications with higher IO demands. Meyrin Main room 300MB/S and 1000 IO operations (both, read and write)
io3 The 'io3' volume type provides the same reliability level as 'standard' volumes, but is meant for applications with higher IO demands. Meyrin Main room 300MB/S and a rate of 5 IO operation per gigabyte with a guaranteed minimum of 500 IO operations and a maximum of 2000 IO operations (both, read and write)
cp1 The 'cp1' volume type provides the same performance level as 'standard' volumes, but is meant for applications with higher reliability demands: 'cp1' volumes are hosted on critical power which guarantees availability even in the event of a prolonged power cut. 'cp1' volumes should hence be used for projects mapped to the critical area. Meyrin Critical Area 80MB/s and 100 IO operations (both, read and write)
cpio1 The 'cpio1' volume type combines the reliability of 'cp1' with the performance of 'io1' volumes. Meyrin Critical Area 120MB/s and 500 IO operations (both, read and write)
cpio2 The 'cpio2' volume type combines the reliability of 'cp1' with the performance of 'io2' volumes. Meyrin Critical Area 300MB/s and 1000 IO operations (both, read and write)
cpio3 The 'cpio3' volume type combines the reliability of 'cp1' with the performance of 'io3' volumes. Meyrin Critical Area 300MB/s and 500 IO operations minimum + 5 IO/GB up to 2000 IO (both, read and write)

Note: the standard type is allocated for projects by default. To request volumes of the other types, please fill out the project quota request form.

Note: The placement of a volume to a backing storage cluster is defined by the storage availability zone where the volume is allocated. See storage availability zones for details. Storage availability zones are currently supported for standard and io1 volume types only.

Volume creation

$ openstack volume create --description "Volume for documentation" --size 10 timvol143
+---------------------+--------------------------------------+
| Field               | Value                                |
+---------------------+--------------------------------------+
| attachments         | []                                   |
| availability_zone   | ceph-geneva-1                        |
| bootable            | false                                |
| created_at          | 2014-12-18T13:27:27.754856           |
| display_description | Volume for Documentation             |
| display_name        | timvol143                            |
| encrypted           | False                                |
| id                  | d8d8be88-f1a4-4120-b1c2-50621a981c74 |
| properties          |                                      |
| size                | 10                                   |
| snapshot_id         | None                                 |
| source_volid        | None                                 |
| status              | creating                             |
| type                | standard                             |
+---------------------+--------------------------------------+

The size is measured in GB.

The reported status will become available when the volume has been created. This status can be checked using openstack volume show.

The volume just created was allocated automatically to the ceph-geneva-1 zone. If you want to create a volume in an specific storage availability zone you can use the parameter --availability-zone during the volume creation such as:

$ openstack volume create --description "Volume for documentation" --availability-zone ceph-geneva-2 --size 10 timvol144

Attaching a volume

Once the volume has been created, it can be attached to the virtual machine.

$ openstack server add volume tim-centos7-143 timvol143

The arguments are:

  • tim-centos7-143 is the virtual machine where you would like to attach the image. This is as previously created using openstack server create.
  • timvol143 is the volume id from openstack volume list as created above

Note: The optional device argument to specify the device name should not be used. It does not work properly, and will be removed in the near future.

The operation can be checked by seeing if this is now shown in the openstack server list command. Log into the VM to check and format the disk:

$ ssh root@tim-centos7-143
# grep vdb /proc/partitions
 252       48   12582912 vdb

Create a file system on it and mount it. Using a volume label is useful in the future to avoid needing to find the exact device name as you attach different volumes. Using a label, such as testvol in the example below, which is the same as the name in OpenStack also makes tracking easier when volumes are not mounted. The filesystem type can be one supported by the Linux distribution but xfs and ext4 are the most widely used.

# mkfs -t ext4 -L testvol /dev/vdb
# mount -L testvol /mnt

If you would like non-root users to be able to access the mounted volume similar to the way /tmp is accessible , you'll need to set the sticky bit on the mount point.

# chmod +t /mnt

The filesystem should be added to /etc/fstab if the desired behaviour is to mount automatically on restart. Using the LABEL parameter here will ensure the correct volume is chosen if multiple volumes are attached.

LABEL=testvol /mnt ext4 noatime,nodiratime,user_xattr,nofail    0       0

Note: The use of nofail is recommended to skip (and not block on) mounting the volume if it is unavailable, e.g. in case of network issues. Remove this option from the fstab line if you want your VM to block the boot process if the volume is unavailable.

Note: The use of nobarrier for the mount options is not recommended as volumes are accessed via a cache, so ignoring the correct ordering of journal commits may leave you with a corrupted file system in case of a hardware problem.

Detaching and deleting a volume

The steps to properly remove disk volumes are: 1. Umount the filesystem on the virtual machine 1. Detach the volume from the virtual machine 1. Delete the volume in openstack

Log into the virtual machine that has the volume mounted and unmount the filesystem stored on it first

# umount /mnt

Note: detaching a volume while it is being mounted is possible, but may lead to the corruption of the data stored.

Then, detach the volume from the virtual machine:

$ openstack server remove volume tim-centos7-143 timvol143

where tim-centos7-143 is the virtual machine and timvol143 is the volume.

Check that the volume is in state 'available' again with openstack volume show timvol143. If that's the case, the volume is now ready to either be attached to another virtual machine or, if it is not needed any longer, to be completely deleted (Note: Deletion cannot be reverted!):

$ openstack volume delete timvol143

Your volume will now go into state 'deleting' and completely disappear from the openstack volume list output

Common error messages

From the openstack volume command, the following errors can be received

Error Cause
VolumeSizeExceedsAvailableQuota: Requested volume or snapshot exceeds allowed Gigabytes quota

ERROR: openstack Request Entity Too Large (HTTP 413)

 Your total space for the volume service exceeds the allowance for the project. If you require further quota, please contact the helpdesk. Please note that additional quota is only granted for shared projects. Additional personal project quota requests will not be accepted.
VolumeLimitExceeded: Maximum number of volumes allowed (N) exceeded You have exceeded the number of volumes. Please contact the helpdesk to request to raise this limit for a project. Additional personal project quota requests will not be accepted.
BadRequest: Failed to delete volume with name or ID: 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) If you are deleting a volume and has associated snapshots, you need to delete them first, before deleting the volume.