About the volumes
Volumes are the blocks storage (similar to SAN LUNs) that can be attached to your instances. Volumes can have any size, and volumes can be of different type, with different performance and cost, depending on the storage configuration of the cloud - HDD, SSD and NVMe storage could be examples of those storage types.
An important feature of a volume that it, while may be attached a specific instance or not attached to any, it does not belong to a specific instance. Thus, it is very easy to detach a volume from one instance and attach to another, for example to move large amount of data between the instances. Also, when you delete an instance, its volumes will not be deleted automatically and can be reused later.
When creating a volume, you need to make several choices:
- You can create a new (empty) volume, a volume from an existing volume snapshot, or a volume from an image. An empty volume will not yet contain any data or file system inside - so before you can use it, it will need to be formatted with a proper file system, supported by your guest OS. If the volume is created from a snapshot, it will contain whatever data was in the original volume at the time the source snapshot has been created. A bootable volume is commonly created from an image - such a volume will copy the image content (typically a pre-installed operating system). Bootable volumes are commonly used to create an instance with a boot volume.
- If available on your cloud, you may have a choice of more than one volume type, with different performance and cost. You can choose the type at the time of the volume creation - note the type cannot be easily changed later without data migration (for example, by attaching both volumes to a Linux instance, and running
dd command to copy the data, block by block).
- Specify the volume size (in GB). If necessary, it is easy to increase the volume size later.
Attaching a volume to an instance
To attach a volume to your instance, do the following:
- Select the volume to be attached.
- Select an instance to attach volume to, and click "Attach"
The final steps should be made inside of the instance. If the volume was empty before, you will need to create a file system before you can mount it - format it either using Disk management on Windows, or a command like
mkfs.ext4 on Linux. If the volume has been used before, this step should be omitted (file system creation will destroy all prior content on the volume, so use with care).
While it is typically very easy to locate the volume on Windows, it may be not that obvious on Linux. The attached volumes get their names assigned as
/dev/vda (that would be the boot volume if used),
/dev/vdb (first attached volume),
/dev/vdc and so on. Then name used for specific volume in the instance, when attached, can also be seen in the volume properties.
The last step would be to
mount the volume (or, assign a drive letter on Windows). On Linux, to make sure the file system still will be accessible after instance restart, you will need to add it to the instance configuration like
Note that attaching volumes to multiple instances at the same time is not supported.
Resizing a Volume
An attached volume can't be resized, so you need to detach it from an instance first. Also, while not enforced by the platform, it is a good idea to unmount the volume inside the instance before detaching it, to make sure it will be in a clean and consistent state.
To resize a volume, click on "Resize" context menu in the portal on the volume you want to resize, and specify the new volume size. The size must be larger than the existing size (so you can only increase volume size).
After that, attach the volume back to the instance. If you simply mount it again, you will not see the increased size - so you need to resize the file system first to make it use the new available space. On Linux, this is done with
resize2fs command (for example,
sudo resize2fs /dev/vdb). On Windows, go to the Disk management, right-click on the volume and select "Extend size".
About bootable volumes
When an instance is created using a bootable volume (instead of using a regular boot disk specified by the flavor), this volume will contain the operating system and its boot instructions. The operating system may either be copied from an image (when volume is created from an image), or also manually installed from an installation media like ISO image. Volume like that is market as "bootable", unlike regular volumes (which are non-bootable). Note that when instance that uses a boot volume is deleted, the volume itself will not be deleted, and should be deleted manually if no longer needed.
It is also possible to re-use a bootable volume, with all the data on it, for a new instance creation. To successfully boot such instance, the bootable volume must contain an operating system from the previous instance deployment.
Common scenarios to use bootable volumes include:
- Changing root volume storage type (for example, if root volume gets on HDD by default, while you want to use SSD).
- Image size exceeding storage limits specified in the flavor (when instance is boot from a volume, storage limitations on the root volume from the flavor are no longer relevant).
- Persistence (you want the instance root disk to stay after instance itself is deleted).
Volume types refers to storage with different hardware back-end, and/or different QoS settings, which result in different performance (and typically different price of the storage). For example, it one volume type may be based on HDD, and another one on SSD drives, providing different level of performance.
Volume type is specified at the time a volume is created. Due to the backend storage implementation specifics, it is not possible to change the volume type for an existing volume. So, if the user needs to migrate an existing volume from one type to another (for example, to move data from HDD to SSD with higher performance), one needs to create a new volume of equal size, attach both old and new volumes to the same instance, and then copy the data block by block with
dd or similar software.
A volume snapshot is a recovery point, created on a specific volume. This recovery point allows later on to access the volume data that existed at the time the snapshot has been created. For example, you can create a snapshot before deploying a large update or upgrading a database schema - so in case the things go wrong, it will be possible to recover the data before the modification.
Unlike a VM snapshot in many hypervisors, volume snapshot does not allow to "rollback" an existing volume to the previous state. Instead, that snapshot can be used to create a new volume, using the snapshot as a starting point - to the new volume will contain the data from the snapshot (note that in this case, the new volume must of the same volume type as the original volume used as the source).
Volume snapshots should not be confused with instance snapshots. While similar in name, implementation is different. Instance snapshots exists as separate object (images) in the image repository, and will be preserved even if original instance has been deleted. Volume snapshots only exist with the volume - if you delete the volume, all its snapshots will be lost (in fact, you cannot delete a volume which contain any snapshots - the snapshots must be deleted first).
Volume snapshots are incremental - that means, when a new snapshot is created, the original volume base becomes read-only, and all further volume modifications will be redirected into the snapshot via CoW (Copy-on-Write). The snapshot size, originally zero, will start growing and can potentially reach full volume size (if every block in that volume will be modified).
A volume may contain multiple snapshots. When this is the case, the new modifications are stored in the latest (newest) snapshot - all previous ones will be read-only. If, however, you will delete an intermediate snapshot, the snapshots on top may depend on the changes stored in that snapshot - as a result, while the snapshot will be deleted, a snapshot next to the deleted one will likely grow in size due to the data merge during the delete operation.