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.
Note | |
---|---|
|
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.
Note | |
---|---|
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 |
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.