openstack-manuals/doc/admin-guide-cloud/source/compute-images-instances.rst

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. Users can create a snapshot, and build a new image based on these snapshots. The Compute service controls instance, image, and snapshot storage and management.

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. OpenStack provides a number of predefined flavors that you can edit or add to.

Note

• For more information about creating and troubleshooting images, see the OpenStack Virtual Machine Image Guide.
• For more information about image configuration options, see the Image services section of the OpenStack Configuration Reference.
• For more information about flavors, see compute-flavors.

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.

The base image state with no running instances

Instance Launch

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 from an image

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.

The end state of an image and volume after the instance exits

Manage instances

Administrative users can manage instances for users in various projects. As an administrative user, you can view, terminate, edit, perform, or migrate an instance. You can perform a soft or hard reboot if needed. You can also view instance logs, or launch a VNC console for an instance.

For information about using the Dashboard to launch instances as an end user, see the OpenStack End User Guide.

Create instance snapshots

1. Log in to the Dashboard and choose the admin project from the drop-down list at the top of the page.
2. On the Admin tab, open the System tab and click the Instances category.
3. Select an instance to create a snapshot from it. From the Actions drop-down list, select Create Snapshot.
4. In the Create Snapshot window, enter a name for the snapshot.
5. Click Create Snapshot. The Dashboard shows the instance snapshot in the Images category.
6. To launch an instance from the snapshot, select the snapshot and click Launch Instance. For information about launching instances, see the OpenStack End User Guide.

Control the state of an instance

1. Log in to the Dashboard and choose the admin project from the drop-down list at the top of the page.

2. On the Admin tab, open the System tab and click the Instances category.

3. Select the instance for which you want to change the state.

4. From the drop-down list in the Actions column, select the state.

   Depending on the current state of the instance, you can choose to pause, un-pause, suspend, resume, soft or hard reboot, or terminate an instance (actions in red color are dangerous).

Track usage

Use the Overview category to track usage of instances for each project.

You can track costs per month by showing meters like number of VCPUs, disks, RAM, and uptime of all your instances.

1. Log in to the Dashboard and choose the admin project from the drop-down list at the top of the page.
2. On the Admin tab, click the Instances category.
3. Select a month and click Submit to query the instance usage for that month.
4. Click Download CSV Summary to download a CSV summary.

Image management

The OpenStack Image service discovers, registers, and retrieves virtual machine images. The service also includes a RESTful API that allows you to query VM image metadata and retrieve the actual image with HTTP requests. For more information about the API, see the OpenStack API Complete Reference and the Python API.

The OpenStack Image service can be controlled using a command-line tool. For more information about using the OpenStack Image command-line tool, see the Manage Images section in the OpenStack End User Guide.

You can store virtual images made available through the Image service in a variety of ways. In order to use these services, you must have a working installation of the Image service, with a working endpoint, and users that have been created in OpenStack Identity. Additionally, you must meet the environment variables required by the Compute and Image service clients.

The Image service supports these back-end stores:

File system

The OpenStack Image service stores virtual machine images in the file system back end by default. This simple back end writes image files to the local file system.

Object Storage

The OpenStack highly available service for storing objects.

Block Storage

The OpenStack highly available service for storing blocks.

VMware

ESX/ESXi or vCenter Server target system.

S3

The Amazon S3 service.

HTTP

OpenStack Image service can read virtual machine images that are available on the Internet using HTTP. This store is read only.

RADOS Block Device (RBD)

Stores images inside of a Ceph storage cluster using Ceph's RBD interface.

Sheepdog

A distributed storage system for QEMU/KVM.

GridFS

Stores images using MongoDB.

Image properties and property protection

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

• The cloud administrator defines core properties, such as the image name.
• The cloud administrator and the image owner can define additional properties, such as licensing and billing information.

The cloud administrator can configure 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 cloud administrators have access.

For unprotected image properties, the cloud administrator can manage core properties and the image owner can manage additional properties.

To configure property protection

To configure property protection, the cloud administrator completes these steps:

1. Define roles or policies in the policy.json file:

   {
       "context_is_admin":  "role:admin",
       "default": "",
   
       "add_image": "",
       "delete_image": "",
       "get_image": "",
       "get_images": "",
       "modify_image": "",
       "publicize_image": "role:admin",
       "copy_from": "",
   
       "download_image": "",
       "upload_image": "",
   
       "delete_image_location": "",
       "get_image_location": "",
       "set_image_location": "",
   
       "add_member": "",
       "delete_member": "",
       "get_member": "",
       "get_members": "",
       "modify_member": "",
   
       "manage_image_cache": "role:admin",
   
       "get_task": "",
       "get_tasks": "",
       "add_task": "",
       "modify_task": "",
   
       "deactivate": "",
       "reactivate": "",
   
       "get_metadef_namespace": "",
       "get_metadef_namespaces":"",
       "modify_metadef_namespace":"",
       "add_metadef_namespace":"",
       "delete_metadef_namespace":"",
   
       "get_metadef_object":"",
       "get_metadef_objects":"",
       "modify_metadef_object":"",
       "add_metadef_object":"",
   
       "list_metadef_resource_types":"",
       "get_metadef_resource_type":"",
       "add_metadef_resource_type_association":"",
   
       "get_metadef_property":"",
       "get_metadef_properties":"",
       "modify_metadef_property":"",
       "add_metadef_property":"",
   
       "get_metadef_tag":"",
       "get_metadef_tags":"",
       "modify_metadef_tag":"",
       "add_metadef_tag":"",
       "add_metadef_tags":""
    }

   For each parameter, use "rule:restricted" to restrict access to all users or "role:admin" to limit access to administrator roles. For example:

   "download_image":
   "upload_image":

2. Define which roles or policies can manage which properties in a property protections configuration file. For example:

   [x_none_read]
   create = context_is_admin
   read = !
   update = !
   delete = !
   
   [x_none_update]
   create = context_is_admin
   read = context_is_admin
   update = !
   delete = context_is_admin
   
   [x_none_delete]
   create = context_is_admin
   read = context_is_admin
   update = context_is_admin
   delete = !

   • A value of @ allows the corresponding operation for a property.
   • A value of ! disallows the corresponding operation for a property.

3. In the glance-api.conf file, define the location of a property protections configuration file:

   property_protection_file = {file_name}

   This file contains the rules for property protections and the roles and policies associated with it.

   By default, property protections are not enforced.

   If you specify a file name value and the file is not found, the glance-api service does not start.

   To view a sample configuration file, see glance-api.conf.

4. Optionally, in the glance-api.conf file, specify whether roles or policies are used in the property protections configuration file:

   property_protection_rule_format = roles

   The default is roles.

   To view a sample configuration file, see glance-api.conf.

Image download: how it works

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, a filesystem 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. Currently, the only store to support the direct download approach is the filesystem store. Configured the approach using the filesystems option in the image_file_urlsection of the nova.conf file on compute nodes.

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.

Instance building blocks

In OpenStack, the base operating system is usually copied from an image stored in the OpenStack 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:

$ nova image-list
+---------------------------+------------------+--------+----------------+
| ID                        | Name             | Status | Server         |
+---------------------------+------------------+--------+----------------+
| aee1d242-730f-431f-88c1-  |                  |        |                |
| 87630c0f07ba              | Ubuntu 14.04     |        |                |
|                           | cloudimg amd64   | ACTIVE |                |
| 0b27baa1-0ca6-49a7-b3f4-  |                  |        |                |
| 48388e440245              | Ubuntu 14.10     |        |                |
|                           | cloudimg amd64   | ACTIVE |                |
| df8d56fc-9cea-4dfd-a8d3-  |                  |        |                |
| 28764de3cb08              | jenkins          | 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.

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

$ nova flavor-list
+----+----------+----------+-----+----------+-----+------+------------+----------+
| ID | Name     | Memory_MB| Disk| Ephemeral| Swap| VCPUs| RXTX_Factor| Is_Public|
+----+----------+----------+-----+----------+-----+------+------------+----------+
| 1  | m1.tiny  | 512      | 1   | 0        |     | 1    | 1.0        | True     |
| 2  | m1.small | 2048     | 20  | 0        |     | 1    | 1.0        | True     |
| 3  | m1.medium| 4096     | 40  | 0        |     | 2    | 1.0        | True     |
| 4  | m1.large | 8192     | 80  | 0        |     | 4    | 1.0        | True     |
| 5  | m1.xlarge| 16384    | 160 | 0        |     | 8    | 1.0        | True     |
+----+----------+----------+-----+----------+-----+------+------------+----------+

By default, administrative users can configure the flavors. You can change this behavior by redefining the access controls for compute_extension:flavormanage in /etc/nova/policy.json on the compute-api server.

Instance management tools

OpenStack provides command-line, web interface, and API-based instance management tools. Third-party management tools are also available, using either the native API or the provided EC2-compatible API.

The OpenStack python-novaclient package provides a basic command-line utility, which uses the nova command. This is available as a native package for most Linux distributions, or you can install the latest version using the pip python package installer:

# pip install python-novaclient

For more information about python-novaclient and other command-line tools, see the OpenStack End User Guide.

Control where instances run

The OpenStack Configuration Reference provides detailed information on controlling where your instances run, including ensuring a set of instances run on different compute nodes for service resiliency or on the same node for high performance inter-instance communications.

Administrative users can specify which compute node their instances run on. To do this, specify the --availability-zone AVAILABILITY_ZONE:COMPUTE_HOST parameter.

Create and manage images

Administrative users can create and manage images for the projects to which you belong. You can create and manage images for users in all projects to which you have administative access.

To create and manage images in specified projects as an end user, see the OpenStack End User Guide.

To create and manage images as an administrator for other users, use the following procedures.

Create images

For details about image creation, see the Virtual Machine Image Guide.

1. Log in to the dashboard.

   Choose the admin project from the drop-down list at the top of the page.

2. On the Admin tab, open the System tab and click the Images category. The images that you can administer for cloud users appear on this page.

3. Click Create Image, which opens the Create An Image window.

Create images

1. In the Create An Image window, enter or select the following values:

   Name	Enter a name for the image.
   Description	Enter a brief description of the image.
   Image Source	Choose the image source from the dropdown list. Your choices are Image Location and Image File.
   Image File or Image Location	Based on your selection, there is an Image File or Image Location field. You can include the location URL or browse for the image file on your file system and add it.
   Format	Select the image format.
   Architecture	Specify the architecture. For example, i386 for a 32-bit architecture or x86_64 for a 64-bit architecture.
   Minimum Disk (GB)	Leave this field empty.
   Minimum RAM (MB)	Leave this field empty.
   Copy Data	Specify this option to copy image data to the Image service.
   Public	Select this option to make the image public to all users.
   Protected	Select this option to ensure that only users with permissions can delete it.

2. Click Create Image.

   The image is queued to be uploaded. It might take several minutes before the status changes from Queued to Active.

Update images

1. Log in to the Dashboard. Choose the admin project from the drop-down list at the top of the page.

2. On the Admin tab, open the System tab and click the Images category.

3. Select the images that you want to edit. Click Edit Image.

4. In the Update Image window, you can change the image name.

   Select the Public check box to make the image public. Clear this check box to make the image private. You cannot change the Kernel ID, Ramdisk ID, or Architecture attributes for an image.

5. Click Update Image.

Delete images

1. Log in to the Dashboard. Choose the admin project from the drop-down list at the top of the page.

2. On the Admin tab, open the System tab and click the Images category.

3. Select the images that you want to delete.

4. Click Delete Images.

5. In the Confirm Delete Images window, click Delete Images to confirm the deletion.

   You cannot undo this action.