OpenStack Image (Glance): Glance Formats, Glance Status flow, Configuration file, Image, and Instance

In today’s blog, we are going to discuss: Image (Glance). We will also cover the topics like Glance Formats, Status flow, configuration file, and image and instance.

So without wasting our time let’s start the discussion!

Overview of OpenStack Image (Glance):

The Glance component of an OpenStack image glance service supports finding, entering, and revoking the server and the disk images. It is considered as a central container or the repository for virtual images. For queries regarding image metadata of virtual machines’ and recovering real images, Glance uses RESTful API. The images of virtual machines that are made available by Glance need to be stored in different locations such as from a normal file system to an object storage system like the Swift project of OpenStack image glance.

For launching new instances, glance stores the images in the form of templates. It is designed as an independent service particularly for those who require organizing huge groups of virtual and server images. It is able to take snaps of working instances which are required for supporting virtual machines as well as its conditions.

Variety of the Formats supported by Glance:

At the time of transferring an image to the glance, it is important to mention the formats related to the virtual machine images. Wide varieties of formats are supported by Glance such as container formats, disk formats, etc. The physical server’s boot drive is the same as the virtual disk just abstracted in a file. Various disk formats are supported by various virtualizations.

Let’s discuss each of these two formats in detail:

Container Formats:

As mentioned earlier, the OpenStack image glance provides support to the container format which defines the formats of the different files and also includes extra metadata concerning the VM.

The OpenStack Glance supports the following container formats.

1. bare: This container format denotes that there is not any container or metadata wrapper for the image.
2. ovf: This Container Format is OVF container format
3. aki: This container format displays glance has stored an Amazon kernel image.
4. ari: This container format displays glance has stored an Amazon ramdisk image.
5. ami: This container format displays glance has stored an Amazon machine image.
6. ova: This container format displays that glance has stored an OVA tar archive file.
7. docker: This container format displays that glance has stored a Docker tar archive related to the container file system.

It is important to note that Glance or any other component of the OpenStack image glance is not currently using the Container formats, therefore ‘bare’ is considered as a container format at the time when an image is transferred in a glance and the meaning of bare is one without a container.

Following command is used for uploading or transferring an image in a glance:

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

The image-create is used in the command for creating an image in glance name expresses the name using which that image is represented, the file option displays the path of the image, qcow2 is used for showing disk format and bare is used for displaying the container format. The meaning of visibility public is that the image can be accessible publicly and the progress indicates the transfer or upload progress bar.

[ ====================================== ] 100%

Disk formats:

The format of the underlying disk image means the disk format of the virtual machine image.

The OpenStack supports the following disk formats:

1. Raw: It is an unstructured disk format.
2. VHD: It is the disk format which is most popularly backed by many OpenStack virtualization technologies excluding KVM.
3. VMDK: This disk format is made popular by VMware.
4. Qcow2: It is a QEMU image format, original format for KVM and QEMU which provides support to the developed functions.
5. VDI: This Virtual Disk Image format is invented by Oracle VM Virtual Box.
6. ISO: This disk format is an archive format for the optical disks.
7. AMI, ARI, and AKI: This disk format displays Amazon machine, ramdisk, and kernel images accordingly.

Status Flow of Glance:

At the time of transferring or uploading an image, the status of the image is shown by the glance status flow. Queuing is the first step just when an image is created, then the image is lined up for a short period of time identifiers, these are then stored to the image and then the image is ready for uploading.

Once the image is queued, it then moves to a status saving that means it is not completely uploaded. The status will be Active once the image is fully uploaded and if the image uploading fails then that image will go to killed or deleted state.

By using a command we can deactivate as well as reactivate the fully transferred or the uploaded image

Following diagram indicates the status flow of the glance:

• queued: In the Glance registry, an image identifier is reserved for an image. The image data has not been uploaded or transferred to the glance. Once the image is created the image size is not set directly to zero.
• saving: Saving indicates that the raw data of an image is at present being transferred or uploaded to the Glance. An image will likely to be never in the saving status if that image is stored with a call to POST /images and also if there is an x-image-meta-location header present.
• active: Active status indicates that an image is completely accessible in a glance, at the time when the image data is transferred or uploaded or once the image gets created the image size is directly set to zero.
• deactivated: This indicates that any user other than admin is not allowed to access image data. If the downloading of an image is restricted then it will also restrict the processes like image exporting and cloning of image which may need the image data.
• killed: This indicates that during the uploading or transferring of the image data an error occurred and due to which it is not possible to read the image.
• deleted: It denotes that the data about an image has been retained by the glance but still it is not available for use. At the later date, the image in this deleted state will be removed or deleted automatically.

Deactivating and reactivating an image:

As mentioned earlier cloud operators can temporarily deactivate an image. If the subsequent operators think that the image is a threat for the cloud environment then they can reactivate that image or they can just delete or remove it.

At the time of carrying out updates of an image, the operator may want to conceal it from all the other users and when the image update is completed, the operator may reactivate the image so that from it the users can boot VM.

root@CONTROLLER:~# glance image- list

ID                                                                            Name

17449a2e-8711-4700-af8f-4399271597c               cirros-0.3.4-x86_64

For deactivating an image a token id is needed.

Steps for deactivating and reactivating an image are as follows:

root@CONTROLLER:~# openstack token issue

Using above command once the image id and the token id are replaced then 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

Now using above command the image will be deactivated.

Now using glance image-list try to list image as follows:

root@CONTROLLER:~# glance image-list

u’deactivated’ is not one of [u’queued’, u’saving’, u’active’, u’killed’, u’deleted’, u’pending_delete’]

Failed validating u’enum’ in schema[u’properties’][u’status’]:

{u’description’ : u’Status of the image (READ-ONLY)’,

U’enum’: [u’queued’,

                 u’saving’,

                 u’active’,

                 u’killed’,

                 u’deleted’,

                 u’pending_delete’],

  u’type’:u’string’}

On instance[u’status’];

      u’deactivated’

The output that we will get is that here the status is deactivated.

The same curl command can be used for reactivating image, but the only change will be in the token id.

The steps for reactivating a deactivated image are as follows:

root@CONTROLLER:~# openstack token issue

Following is the curl command:

root@CONTROLLER:~# curl –x POST –H ‘x-Auth-Token:88878e52d01f43c29a915b2220295641’ http:// 192.168.1.110:9292/v2/images/17449a2e-8711-4700-af8f-439927159b7c/actions/reactive

After this check by executing glance image-list as follows:

root@CONTROLLER:~# glance image-list

Configuration Files in Glance:

• Glance-api.conf: This is a configuration file for API image service.
• Glance-registry.conf: This is a configuration file for glance image registry that saves metadata related to the images.

• Glance-scrubber.conf: This service is used for cleaning up the images which have been removed or deleted. In a single installation, more than one glance-scrubber may be executed but it can act as a clean-up scrubber only once in a scrubber.conf file.

The main queue of images which required to be deleted is maintained by the coordination between the cleanup scrubber and other glance scrubbers.

Some of the important items are also specified by the glance-scrubber.conf file. Like the time between runs, before the deletion of the images, the length of time images may be pending along with the options of the registry connectivity. This glance-scrubber can work as a periodic job or as a long-running daemon.

• policy.json: It applies additional access control to the image service as it is a security feature in a glance. We can also describe the roles and policies.

Let’s discuss glance Image and Instance:

 As mentioned earlier, glance stores the disk images as templates and the storage and management of the images are controlled by the image services.

Instances are the independent VM that works on the compute node and the instances are managed by the compute nodes. It is possible for the user to launch whatever number of instances using the same image.

If any modifications are performed on the instance, it does not affect the base image. The snaps of working instances taken can be used for initiating new instances.

Once an instance is launched, it is required to specify the flavor because it indicates the virtual resource. These flavors describe an instance has how many virtual CPUs, how much RAM is available, and the size of the ephemeral disks.

A collection of predefined flavors is provided by OpenStack image which we can create as well as modify the required flavors.

When we launch an instance we need to specify the flavor, which represents a 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 image glance provides a set of predefined flavors we can create and edit our own flavors.
It is required to select an image, flavor, or any other optional attribute before launching any instance. The specific flavor selected offers a root volume which is specified as vda and any extra ephemeral storage is specified as vdb and cinder-volume is linked to the third virtual disk and specified as vdc.

That’s all for today! I think you find this information helpful. Please do not forget to leave a Comment in the comment section below. Thank you for reading the blog! See you soon next time with another exciting blog!

People also read:

OpenStack object storage swift component and how to use it and what are its components

Information about OpenStack image glance component and also how to manage images

Understanding OpenStack networking neutron components and its concepts/