Working with Images and Instances

Virtual machine images contain a virtual disk that holds a bootable operating system on it. Disk images provide templates for virtual machine file systems. The Image service controls image storage and management.

Instances are the individual virtual machines that run on physical compute nodes inside the cloud. Users can launch any number of instances from the same image. Each launched instance runs from a copy of the base image. Any changes made to the instance do not affect the base image. Snapshots capture the state of an instances running disk. You can create a snapshot, and build a new image based on these snapshots. The Compute service controls instance, image, and snapshot storage and management.

Note
You cannot snapshot a volume with NFS.

When you launch an instance, you must choose a flavor, which represents a set of virtual resources. Flavors define virtual CPU number, RAM amount available, and ephemeral disks size. Users must select from the set of available flavors defined on their cloud. Metacloud provides a number of predefined flavors that you can edit or add to.

You can add and remove additional resources from running instances, such as persistent volume storage, or public IP addresses. The example used in this chapter is of a typical virtual system within an OpenStack cloud. It uses the cinder-volume service, which provides persistent block storage, instead of the ephemeral storage provided by the selected instance flavor.

This diagram shows the system state prior to launching an instance. The image store has a number of predefined images, supported by the Image service. Inside the cloud, a compute node contains the available vCPU, memory, and local disk resources. Additionally, the cinder-volume service stores predefined volumes.

Base image state with no running instances

Launching an Instance

To launch an instance, select an image, flavor, and any optional attributes. The selected flavor provides a root volume, labeled vda in this diagram, and additional ephemeral storage, labeled vdb. In this example, the cinder-volume store is mapped to the third virtual disk on this instance, vdc.

Instance creation

The Image service copies the base image from the image store to the local disk. The local disk is the first disk that the instance accesses, which is the root volume labeled vda. Smaller instances start faster. Less data needs to be copied across the network.

The new empty ephemeral disk is also created, labeled vdb. This disk is deleted when you delete the instance.

The compute node connects to the attached cinder-volume using iSCSI. The cinder-volume is mapped to the third disk, labeled vdc in this diagram. After the compute node provisions the vCPU and memory resources, the instance boots up from root volume vda. The instance runs and changes data on the disks (highlighted in red on the diagram). If the volume store is located on a separate network, the my_block_storage_ip option specified in the storage node configuration file directs image traffic to the compute node.

Note
Some details in this example scenario might be different in your environment. For example, you might use a different type of back-end storage, or different network protocols. One common variant is that the ephemeral storage used for volumes vda and vdb could be backed by network storage rather than a local disk.

When you delete an instance, the state is reclaimed with the exception of the persistent volume. The ephemeral storage is purged. Memory and vCPU resources are released. The image remains unchanged throughout this process.

End state of an image nd volume after the instance exits

Image Properties and Property Protection

An image property is a key- and value-pair that you, an administrator, or the image owner attaches to a Metacloud Image service image, as follows:

  • You or an administrator defines core properties, such as the image name.
  • You, an administrator, or the image owner defines additional properties, such as licensing and billing information.
  • You or an administrator configures any property as protected, which limits which policies or user roles can perform CRUD operations on that property. Protected properties are generally additional properties to which only administrators have access. For unprotected image properties, an administrator can manage core properties and the image owner can manage additional properties.

Downloading an Image

Prior to starting a virtual machine, transfer the virtual machine image to the compute node from the Image service. How this works can change depending on the settings chosen for the compute node and the Image service.

Typically, the Compute service will use the image identifier passed to it by the scheduler service and request the image from the Image API. Though images are not stored in glance—rather in a back end, which could be Object Storage or any other supported method—the connection is made from the compute node to the Image service and the image is transferred over this connection. The Image service streams the image from the back end to the compute node.

It is possible to set up the Object Storage node on a separate network, and still allow image traffic to flow between the Compute and Object Storage nodes. Configure the my_block_storage_ip option in the storage node configuration file to allow block storage traffic to reach the Compute node.

Certain back ends support a more direct method, where on request the Image service will return a URL that links directly to the back-end store. You can download the image using this approach.

Compute nodes also implement caching of images, meaning that if an image has been used before it won’t necessarily be downloaded every time. Information on the configuration options for caching on compute nodes can be found in the Configuration Reference.

Using Instance Building Blocks

In Metacloud, the base operating system is usually copied from an image stored in the Metacloud Image service. This results in an ephemeral instance that starts from a known template state and loses all accumulated states on shutdown.

You can also put an operating system on a persistent volume in Compute or the Block Storage volume system. This gives a more traditional, persistent system that accumulates states that are preserved across restarts. To get a list of available images on your system, run:

$ openstack image list
+------------+-------------------------+--------+
| ID         | Name                    | Status |
+------------+-------------------------+--------+
| <image_id> | cirros-0.3.4-x86_64     | active |
| <image_id> | ubuntu16.04             | active |
| <image_id> | Ops Manager 1.7.7       | active |
+------------+-------------------------+--------+

The displayed image attributes are:

  • ID—Automatically generated UUID of the image.
  • Name—Free form, human-readable name for the image.
  • Status—The status of the image. Images marked ACTIVE are available for use.
  • Server—For images that are created as snapshots of running instances, this is the UUID of the instance the snapshot derives from. For uploaded images, this field is blank.

Virtual hardware templates are called flavors. The default installation provides five predefined flavors; only administrators can configure them.

For a list of flavors that are available on your system, run:

$ openstack flavor list
+-------------+-----------------+-------+------+-----------+-------+-----------+
| ID          | Name            |   RAM | Disk | Ephemeral | VCPUs | Is Public |
+-------------+-----------------+-------+------+-----------+-------+-----------+
| <flavor_id> | m1.medium       |  4096 |   40 |         0 |     2 | True      |
| <flavor_id> | m1.xlarge-20    |  8000 |    0 |        30 |     2 | True      |
| <flavor_id> | m1.xlarge       | 16384 |  160 |         0 |     8 | True      |
| <flavor_id> | m1.large        |  8192 |   80 |         0 |     4 | True      |
| <flavor_id> | m1.small        |  2048 |   20 |         0 |     1 | True      |
+-------------+-----------------+-------+------+-----------+-------+-----------+

Controlling Where Instances Run

You can specify the compute node instances run. To do this, specify the --availability-zone AVAILABILITY_ZONE:COMPUTE_HOST parameter.

Launching Instances with UEFI

Unified Extensible Firmware Interface (UEFI) is a standard firmware designed to replace legacy BIOS. There is a slow but steady trend for operating systems to move to the UEFI format and, in some cases, make it their only format.

To configure a UEFI environment:

To successfully launch an instance from an UEFI image in QEMU/KVM environment, you must install the following packages on compute nodes:

  • OVMF—a port of Intel’s tianocore firmware to QEMU virtual machine.

  • libvirt—which has been supporting UEFI boot since version 1.2.9.

Because default UEFI loader path is /usr/share/OVMF/OVMF_CODE.fd, you must create one link to this location after UEFI package is installed.

To upload UEFI images:

To launch instances from a UEFI image, you must upload one UEFI image. To do so, hw_firmware_type property must be set to uefi when the image is created. For example:

 $ openstack image create --container-format bare --disk-format qcow2 \ --property hw_firmware_type=uefi --file /tmp/cloud-uefi.qcow --name uefi

After that, you can launch instances from this UEFI image.