Openstack Glance

The openstack Glance is an image service which provides discovering, registering, retrieving for disk and server images.The OpenStack Glance is a central repository for virtual images. Glance has RESTful API that allows querying of VM image metadata as well as retrieval of the actual images. VM images made available through glance can be stored in variety of locations from simple file system to object storage systems such as OpenStack Swift project.
In Glance the images are stored as template, which is used for launching new instances. Glance has been designed to be a standalone service for those needing to organize large sets of virtual disk images. Glance provides an end-to-end solution for cloud disk image management. It also can take snapshots from running instance for backing up VM’s and their states.

Glance Components

Glance has the following components:

glance-api, which accepts API calls for image discovery, retrieval and storage.
glance-registry, which stores, processes, and retrieves metadata information for images.
database, which stores image metadata
storage repository, which integrates with various outside OpenStack components such as regular file systems, Amazon S3 and HTTP for image storages.

Glance accepts API requests for images from end-users or Nova components and can store its files in the object storage service,swift or other storage repository.

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.

Glance Architecture

Glance has a client-server architecture and provides Rest API through which request to server are performed. The request from client is accepted through Rest API and wait for Keystone authentication. Glance Domain controller manages all the internal operations, which is divided in to layers, each layer implements its own tasks.
Glance store is the communication layer between glance and external storage backends or local file system and provides uniform interface to access.Glance uses SQL central Database which is accessible for every components in the system.

The Glance architecture consists of several components:

Client – any application that uses Glance server.
REST API – exposes Glance functionality via REST.
Database Abstraction Layer (DAL) – an application programming interface which unifies the communication between Glance and databases.
Glance Domain Controller – middleware that implements the main Glance functionalities: authorization, notifications, policies, database connections.
Glance Store – organizes interactions between Glance and various data stores.
Registry Layer – optional layer organizing secure communication between the domain and the DAL by using a separate service.

Glance Formats

When we are uploading an image in to glance we need to specify the formats of Virtual machine images. Glance supports wide variety of formats like Disk Formats and Container Formats. Virtual disk are similar to a physical server’s boot driver, only condensed in to a file. Different virtualizations supports different disk formats.

Disk Formats
The Disk Formats of a virtual machine image is the format of the underlying disk image. Following are the disk formats supported by OpenStack glance.

Container Formats
As said OpenStack glance also support the concept of container format, which describes the file formats and contains additional metadata about the actual virtual machine.
Following are the container formats which supported in OpenStack glance.

Note that Container Formats are not currently used by Glance or other OpenStack components. So ‘bare’ is given as container format while we upload an image in glance, bare mean without container.

Images are uploaded in glance by using following command

root@CONTROLLER:~# glance image-create --name "cirros-0.3.4-x86_64" --file /tmp/images/cirros-0.3.4-x86_64-disk.img --disk-format qcow2 --container-format bare --visibility public --progress

Here image-create is used to create image in glance name represents the name in which the image is displayed, file shows the path of image, disk format is given as qcow2 and container format as bare. Visibility public means the image could be publicly accessible, progress represents the upload progress bar.

Glance Status Flow

Glance status flow shows the status of image while uploading. When we create an image first step is queuing, image is queued for a short time identifiers, are reserved to the image and ready to upload. After queuing image goes to a status Saving which means not fully uploaded. Once the image is fully uploaded then the status will be in Active. When uploading fails it will goes to killed or deleted state. We can deactivate and reactivate the fully uploaded image by using a command.
The diagram shown below represent the status flow of glance.

queued

The image identifier has been reserved for an image in the Glance registry. No image data has been uploaded to Glance and the image size was not explicitly set to zero on creation.

saving

Denotes that an image’s raw data is currently being uploaded to Glance. When an image is registered with a call to POST /images and there is an x-image-meta-location header present, that image will never be in the saving status (as the image data is already available in some other location).

active

Denotes an image that is fully available in Glance. This occurs when the image data is uploaded, or the image size is explicitly set to zero on creation.

deactivated

Denotes that access to image data is not allowed to any non-admin user. Prohibiting downloads of an image also prohibits operations like image export and image cloning that may require image data.

killed

Denotes that an error occurred during the uploading of an image’s data, and that the image is not readable.

deleted

Glance has retained the information about the image, but it is no longer available to use. An image in this state will be removed automatically at a later date.

Deactivating and Reactivating an image

The cloud operators are able to deactivate (temporary) an image. Later operators can reactivate it or just remove it if they believe the image is a threat for the cloud environment.While performing the update of an image the operator might want to hide it from all the users. Then when the update is complete he can reactivate the image so the users can boot virtual machines from it.

We need token id and image id to deactivate an image, following are the steps to deactivate and reactivate an image

Once replace the image id and token id with above execute the curl command

root@CONTROLLER:~# curl -X POST -H 'X-Auth-Token: fbdab45ff753408c9e042aa6892e055b' http://192.168.1.110:9292/v2/images/17449a2e-8711-4700-af8f-439927159b7c/actions/deactivate

Here the image is deactivated, try to list image by using glance image-list

We will get Output like this here the status is deactivated.

We can use same curl command for reactivating it only change will be the token id, following are the steps to reactivate an deactivated image.

root@CONTROLLER:~# curl -X POST -H 'X-Auth-Token: 88878e52d01f43c29a915b2220295641' http://192.168.1.110:9292/v2/images/17449a2e-8711-4700-af8f-439927159b7c/actions/reactivate

Next check by excecuting glance image-list

Glance Configuration Files

Glance-api.conf : Configuration file for image service API.

Glance-registry.conf : Configuration file for glance image registry which stores metadata about images.

glance-scrubber.conf : Utility used to clean up images that have been deleted. Multiple glance-scrubber can be run in a single deployment, but only once can act as clean-up scrubber in the scrubber.conf file. The clean-up scrubber coordinates other glance scrubbers by maintaining a master queue of images that need to be removed.The glance-scrubber.conf file also specifies important configuration items such as the time between runs, length of time images can be pending before their deletion as well as registry connectivity options. Glance-scrubber can run as a periodic job or long-running daemon.

policy.json : Additional Access control that apply to image service. In this we can define roles and policies, it is the security feature in the OpenStack glance.

Image and Instance

As said before Disk images are stored as template. Image service controls storage and management of images. Instance are the individual virtual machine which run on compute node, compute node manages the instances. User can launch any number of instances from same image.Each launched instance is made by copy of base image, so any modification on the instance don’t affect the base image. We can take the snapshot of running instance and can be used for launching another instance.

When we launch an instance we need to specify the flavor, which represents virtual resource. Flavors define how many virtual CPUs an instance has, the amount of RAM available to it, and the size of its ephemeral disks. OpenStack provides set of predefined flavors we can create and edit our own flavors.
The diagram shown below indicates the system state prior to launching an instance. The image store, has number of predefined images, compute node contain available vcpu, memory and local disk resources and cinder-volume contains number of predefined volumes.

Before launching instance select an image, flavor and any optional attributes. Selected flavor provides a root volume, labelled as vda and an additional ephemeral storage is labelled as vdb and cinder-volume is mapped to third virtual-disk and call it as vdc.

In this figure the base image is copied to the local disk from the image store. vda is the first disk that the instances accesses, instances starts faster if the size of image is smaller as less data needs to be copied across the network. vdb is an empty ephemeral disk created along with the instance, it will be deleted when instance terminates.
vdc connects to the cinder-volume using iSCSI.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. 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.

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 this process.

Posted January 8, 2016 by shameem