Disk images provide templates for virtual machine file systems. The Image Service manages storage and management of images. Instances are the individual virtual machines that run on physical compute nodes. Users can launch any number of instances from the same image. Each launched instance runs from a copy of the base image so that any changes made to the instance do not affect the base image. You can take snapshots of running instances to create an image based on the current disk state of a particular instance. The Compute services manages instances. When you launch an instance, you must choose a flavor, which represents a set of virtual resources. Flavors define how many virtual CPUs an instance has and the amount of RAM and size of its ephemeral disks. OpenStack provides a number of predefined flavors that you can edit or add to. Users must select from the set of available flavors defined on their cloud. 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 or the Flavors section in the OpenStack Operations Guide. 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, fronted by the Image service (glance) has a number of predefined images. Inside the cloud, a compute node contains the available vCPU, memory, and local disk resources. Additionally, the cinder-volume service provides a number of predefined volumes.

To launch an instance, select an image, a flavor, and other 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.

The base image is copied from the image store to the local disk. The local disk is the first disk that the instance accesses, and is labeled vda. By using smaller images, your instances start up faster as less data needs to be copied across the network. A new empty disk, labeled vdb is also created. This is an empty ephemeral disk, which is destroyed when you delete the instance. The compute node is attached to the cinder-volume using iSCSI, and maps to the third disk, vdc. The vCPU and memory resources are provisioned and the instance is booted from vda. The instance runs and changes data on the disks as indicated in red in the diagram. Some of the 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 the instance is deleted, 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.

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. Admin users can specify an exact compute node to run on using the command --availability-zone availability-zone:compute-host