Volumes are network-based block storage devices that provide high performance, high availability and flexible storage for Cloud Servers.
Volumes can be resized instantly at any time and additional volumes (up to 6 in total) can be attached to a cloud server at any time.
Volumes can be created in two ways:
- During cloud server creation when using a block storage server type – a single boot volume is created by default from the chosen OS image
- Individually, as required, using the volumes API
An initial volume size can be specified during volume creation and defaults to the minimum volume size if not specified. Volumes must be a minimum of 40GB and maximum of 4TB.
Volume size can be increased at any time up to the maximum volume size, but cannot be decreased in size.
When creating a new volume an optional
filesystem_type (either ext4 or xfs)
can be specified which will automatically create a corresponding filesystem on
the volume. When a filesystem type is specified, an optional 12 character
filesystem_label can also be specified which can be used to reference the
formatted filesystem within a cloud server (see Persistent block device naming).
The filesystem attributes on a Volume cannot be changed via the API after creation.
Persistent block device naming
When servers have more than one block device, the ordering of OS-assigned device
/dev/vdc etc) should not be relied upon to be consistent
and it is possible for device names to change order after a reboot.
To solve this, there are two attributes which can be used to provide persistent block device names and allow referencing a volume consistently inside a cloud server.
The serial is a string of up to 20 characters and defaults to the volume id (vol-xxxxx). The volume serial can be edited, but only when a volume is detached.
Volume serials can usually be referenced within a Linux-based cloud servers
using the symbolic links present in
$ ls -l /dev/disk/by-id/ total 0 lrwxrwxrwx 1 root root 9 Apr 26 15:51 virtio-my-vol-serial -> ../../vdc lrwxrwxrwx 1 root root 9 Apr 26 15:24 virtio-vol-xi757 -> ../../vda lrwxrwxrwx 1 root root 10 Apr 26 15:24 virtio-vol-xi757-part1 -> ../../vda1 lrwxrwxrwx 1 root root 11 Apr 26 15:24 virtio-vol-xi757-part14 -> ../../vda14 lrwxrwxrwx 1 root root 11 Apr 26 15:24 virtio-vol-xi757-part15 -> ../../vda15 lrwxrwxrwx 1 root root 9 Apr 26 15:26 virtio-vol-yf8iz -> ../../vdb
The filesystem label, if provided (see Automatic formatting) can also be used to reference the formatted volume’s filesystem within a cloud server.
Labels can usually be referenced within Linux-based cloud servers using the
symbolic links present in
$ ls -l /dev/disk/by-label/ total 0 lrwxrwxrwx 1 root root 11 Apr 26 15:24 UEFI -> ../../vda15 lrwxrwxrwx 1 root root 10 Apr 26 15:24 cloudimg-rootfs -> ../../vda1 lrwxrwxrwx 1 root root 9 Apr 26 15:26 my-vol-label -> ../../vdb
Cloud servers must have one attached volume designated as the boot volume, which must contain a bootable filesystem.
The boot volume can be changed when the cloud server is
(i.e shut down) by attaching a different volume and specifying it as the boot volume.
A volume can be created from an image which will copy the contents of the image to the volume. This is the default method used when creating a new cloud server specifying an image and a block storage server type.
delete_with_server attribute is used to determine whether the volume
should be deleted automatically when the cloud server it is currently attached
to is deleted.
By default, volumes created automatically during server creation have
delete_with_server set to true (which aligns with how standard SSD cloud
servers work). Volumes created independently of a cloud server are set to
false, unless specified otherwise.
As with other Brightbox cloud resources, Volumes support resource locking to prevent accidental deletion.
Volumes can be attached to a cloud server at any time (up to a maxium of 6 volumes).
Attaching a volume to a cloud server makes it available as a block device, but it will need to be mounted within the cloud server before use.
Volumes can be detached from a cloud server at any time but no checks are made as to whether it is in use within the cloud server. Ensure that the relevant filesystem is unmounted before detaching the volume or data loss can occur.