There are two fundamental requirements for a computing system, software and hardware. Virtualization and cloud frameworks tend to blur these lines and some of your "hardware" may actually be "software" but conceptually you still need an operating system and something to run it on.
In OpenStack the base operating system is usually copied from an "image" stored in the Glance image service. This is the most common case and results in an ephemeral instance which starts from a know templated state and lose all accumulated state on shutdown. It is also possible in special cases to put an operating system on a persistent "volume" in the Nova-Volume or Cinder volume system. This gives a more traditional persistent system that accumulates state which is 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 12.04 cloudimg amd64 | ACTIVE | | | 0b27baa1-0ca6-49a7-b3f4-48388e440245 | Ubuntu 12.10 cloudimg amd64 | ACTIVE | | | df8d56fc-9cea-4dfd-a8d3-28764de3cb08 | jenkins | ACTIVE | | +--------------------------------------+-------------------------------+--------+--------------------------------------+
The displayed image attributes are
ID: the automatically generate UUID of the image
Name: a free form human readable name given to the image
Status: shows the status of the image ACTIVE images are available for use.
Server: for images that are created as snapshots of running instance this is the UUID of the instance the snapshot derives from, for uploaded images it is blank
Virtual hardware templates are called "flavors" in
OpenStack. The default install provides a range of
five flavors. These are configurable by admin users
(this too is configurable and may be delegated by
redefining the access controls for
"compute_extension:flavormanage" in
/etc/nova/policy.json on the
compute-api server) . To get a list of available
flavors on your system run:
$ nova flavor-list
+----+-------------+-----------+------+-----------+------+-------+-------------+-----------+-------------+
| ID | Name | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public | extra_specs |
+----+-------------+-----------+------+-----------+------+-------+-------------+-----------+-------------+
| 1 | m1.tiny | 512 | 0 | 0 | | 1 | 1.0 | True | {} |
| 2 | m1.small | 2048 | 10 | 20 | | 1 | 1.0 | True | {} |
| 3 | m1.medium | 4096 | 10 | 40 | | 2 | 1.0 | True | {} |
| 4 | m1.large | 8192 | 10 | 80 | | 4 | 1.0 | True | {} |
| 5 | m1.xlarge | 16384 | 10 | 160 | | 8 | 1.0 | True | {} |
+----+-------------+-----------+------+-----------+------+-------+-------------+-----------+-------------+
The nova flavor-create command allows authorized users to create new flavors. Additional flavor manipulation commands can be shown with the command nova help |grep flavor
Flavors define a number of elements
ID: a unique numeric id
Name: a descriptive name.
xx.size_nameis conventional not required, though some third party tools may rely on it.Memory_MB: virtual machine memory in megabytes
Disk: virtual root disk size in gigabytes. This is an ephemeral disk the base image is copied into. When booting from a persistent volume it is not used. The "0" size is a special case which uses the native base image size as the size of the ephemeral root volume.
Ephemeral: specifies the size of a secondary ephemeral data disk. This is an empty, unformatted disk and exists only for the life of the instance.
Swap: optional swap space allocation for the instance
VCPUs: number of virtual CPUs presented to the instance
RXTX_Factor: optional property allows created servers to have a different bandwidth cap than that defined in the network they are attached to. This factor is multiplied by the rxtx_base property of the network. Default value is 1.0 (that is, the same as attached network).
Is_Public: Boolean value, whether flavor is available to all users or private to the tenant it was created in. Defaults to True.
extra_specs: additional optional restrictions on which compute nodes the flavor can run on. This is implemented as key/value pairs that must match against the corresponding key/value pairs on compute nodes. Can be used to implement things like special resources (e.g., flavors that can only run on compute nodes with GPU hardware).
