Boot from volume
Virtual machines by default are created on the local disk of the hypervisor. This means that a hypervisor failure can make the virtual machine unavailable. Depending on the failure, the virtual machine contents may be lost. For many cloud applications, this is covered by techniques such as load balancing.
One approach to improve the availability in these cases is to boot from a volume. This involves a number of steps
- Create a volume using an image as the source
- Create a virtual machine using this volume
Creating a volume from an image
Identify the image for the initial volume contents from openstack image list. In the example below, this is image id 1c5607b5-d373-4696-ad37-e2dc764f99be.
Creating a disk from this image with a size of 80GB is as follows.
$ openstack volume create --image 1c5607b5-d373-4696-ad37-e2dc764f99be --size 80 --description "From CC7" my-volume
+---------------------+--------------------------------------+
| Field | Value |
+---------------------+--------------------------------------+
| attachments | [] |
| availability_zone | nova |
| bootable | false |
| created_at | 2020-12-14T15:07:35.802654 |
| display_description | From CC7 |
| display_name | my-volume |
| encrypted | False |
| id | de6e41e7-1fce-440e-af6d-898f145acc2d |
| image_id | 1c5607b5-d373-4696-ad37-e2dc764f99be |
| properties | |
| size | 80 |
| snapshot_id | None |
| source_volid | None |
| status | creating |
| type | standard |
+---------------------+--------------------------------------+
Checking the status again using openstack volume show will allow the volume creation to be followed.
- downloading means that the volume contents is being transferred from the image service to the volume service
- available means the volume can now be used for booting. A set of volume_image meta data is also copied from the image service.
Creating a VM using this volume
$ openstack server create --flavor m2.medium --key-name lxplus --volume de6e41e7-1fce-440e-af6d-898f145acc2d my-vm
+--------------------------------------+-------------------------------------------------------------------------+
| Field | Value |
+--------------------------------------+-------------------------------------------------------------------------+
| OS-DCF:diskConfig | MANUAL |
| OS-EXT-AZ:availability_zone | nova |
| OS-EXT-STS:power_state | 0 |
| OS-EXT-STS:task_state | scheduling |
| OS-EXT-STS:vm_state | building |
| OS-SRV-USG:launched_at | None |
| OS-SRV-USG:terminated_at | None |
| accessIPv4 | |
| accessIPv6 | |
| addresses | |
| config_drive | |
| created | 2020-12-14T15:19:09Z |
| flavor | m2.medium (3) |
| hostId | |
| id | 6ae774f8-6f53-46a5-ae02-37166037a8ed |
| image | CC7 Server - x86_64 [2014-10-31] (1c5607b5-d373-4696-ad37-e2dc764f99be) |
| key_name | None |
| name | my-vm |
| os-extended-volumes:volumes_attached | [{u'id': u'de6e41e7-1fce-440e-af6d-898f145acc2d'}] |
| progress | 0 |
| properties | |
| security_groups | [{u'name': u'default'}] |
| status | BUILD |
| project_id | 841615a3-ece9-4622-9fa0-fdc178ed34f8 |
| updated | 2020-12-14T15:19:09Z |
| user_id | my-user-name |
+--------------------------------------+-------------------------------------------------------------------------+
Note:
- When booting a VM from Volume the "OS" and "OS_VERSION" fields in LanDB are set to "UNKNOWN". For some CERN services the "OS" is required (ex: kerberos). To set the "OS" use the instance metadata "landb-os" at boot time. For example, for LINUX images add "--property landb-os=LINUX" when booting the instance from volume.
Errors when creating a machine from volume
Target flavor is too small
When a volume is created from a machine snapshot (or an image in general), the minimum size requirement of the image is carried over to the volume metadata. In order to create an instance from this volume, the flavor must provide a size larger than the volume's size requirement. A typical error when this is not the case would be:
"Flavor's disk is too small for requested image. Flavor disk is 75161927680 bytes, image is 85824438272 bytes."
As the size requirements are not applicable for volumes anyway, the easiest is to remove the corresponding metadata from the volume:
$ openstack volume unset --image-property 'min_disk' <volume name>