Images and instancesDisk 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
Flavors 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 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.Control where instances runThe
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 on which compute node to run instances. To do so,
specify the --availability-zone
AVAILABILITY_ZONE:COMPUTE_HOST
parameter.