Image Service (Glance)

Overview

firstcolo provides and maintains a set of images in the firstcloud. As soon as vendors publish new images, we will verify their origin, test them and publish them automatically. This means that we only publish images that are correctly signed. We don't make any changes in vendor images, to keep checksums intact. That allows our customers to validate image origin if needed.

You can view and manage images both via the OpenStack API and CLI, as well as using the Dashboard (GUI).

All images that have the tag "managed_by_firstcolo" assigned will be updated and verified by us.

Disclaimer

Although we offer images for various distributions, we don't provide support or assume further responsibility for them.

If you need to maintain your own set of images, you can upload them yourself as well using the OpenStack API. It is possible to use tools like Hashicorp Packer to build your own images, for example with certain preinstalled software.

Guidance on building images is available in the documentation for each distribution. For example, you can refer to the Ubuntu documentation for instructions on creating your own Ubuntu image.

Image visibility

Every image in Glance has a visibility property that controls who can discover and use it. There are four visibility levels:

Private

A private image is accessible to all members of the owning project. No other project can see, discover, or boot from it. This is the default visibility when you upload a new image. To share a private image with other projects, you must first change its visibility to shared or community.

Public

A public image is readable by all users and appears in every user's default image list. Only administrators can set an image to public visibility.

Shared

A shared image can be accessed by the owner and by specific projects that the owner explicitly grants access to. The owner must first set the image visibility to shared and then add individual projects as image members.

# Set the image to shared visibility
openstack image set --shared <image-id>

# Add a project as a member
openstack image add project <image-id> <project-id>

Members with a pending status can already see the image details and boot from it, but the image will not appear in their default image list. The target project must accept the shared image for it to show up there:

openstack image set --accept <image-id>

Note that an image can have shared visibility with an empty member list — it simply means no one besides the owner has access yet.

Community

A community image is readable by all users — anyone can see its details and boot from it. However, it does not appear in the default image list of every user. Only the owner and explicitly accepted members see it in their default list. Other users can discover community images by filtering explicitly, for example by image ID or by owner.

Like shared images, community images maintain a member list. The owner can add projects as members, and those members can accept the image so it shows in their default list. The difference to shared images is that all users can access and boot a community image, not just members. This makes community images useful for offering images to a wider audience without cluttering everyone's image list.

# Make an image available to the community
openstack image set --community <image-id>

# List community images
openstack image list --community

Comparison

	Private	Shared	Community	Public
Accessible by owner	Yes	Yes	Yes	Yes
Accessible by specific members	No	Yes	Yes	Yes
Accessible by all users	No	No	Yes	Yes
In owner's default image list	Yes	Yes	Yes	Yes
In members' default image list	—	After accept	After accept	Yes
In all users' default image list	No	No	No	Yes
Requires admin to set	No	No	No	Yes

Image protection

The protected flag is a boolean property that prevents an image from being deleted. When set to true, any attempt to delete the image will be rejected by the API.

This is useful for safeguarding important or production images against accidental deletion.

# Protect an image
openstack image set --protected <image-id>

# Unprotect an image (to allow deletion)
openstack image set --unprotected <image-id>

Note

The protected flag only prevents deletion. It does not restrict other operations such as updating image properties or downloading the image data.

Image properties

When creating or uploading an image, you can set additional properties that describe the image and influence how instances are booted from it. See the Upload Images how-to guide for step-by-step instructions on uploading images via CLI and GUI.

Architecture

The architecture property specifies the CPU architecture the image is designed to run on (e.g. x86_64, aarch64, i686). The compute scheduler can use this information to place instances on hosts with a matching architecture.

openstack image set --architecture x86_64 <image-id>

Kernel and RAMdisk (AMI-style images)

The kernel_id and ramdisk_id properties are relevant for AMI-style images. Unlike whole-disk images (e.g. qcow2), AMI-style images store the kernel, RAMdisk (initrd), and root filesystem as separate Glance images.

kernel_id — The ID of an image stored in Glance that should be used as the kernel when booting the instance.
ramdisk_id — The ID of an image stored in Glance that should be used as the RAMdisk (initial RAM filesystem) when booting the instance.

When these properties are present, the image is treated as a partition image (AMI-style). When they are absent, the image is treated as a whole-disk image, which is the more common format in modern OpenStack deployments.

# Upload the kernel and ramdisk as separate images first
openstack image create --disk-format aki --file vmlinuz "My Kernel"
openstack image create --disk-format ari --file initrd "My RAMdisk"

# Then set them on the AMI image
openstack image set --property kernel_id=<kernel-image-id> --property ramdisk_id=<ramdisk-image-id> <image-id>

Info

Most modern cloud images use the whole-disk format (qcow2 or raw) with the kernel and initrd embedded inside the image. AMI-style images with separate kernel and RAMdisk are primarily used for compatibility with Amazon EC2 workflows.

Operating system metadata

These properties describe the operating system inside the image. They help the compute service make correct decisions (e.g. disk layout, hostname handling) and make it easier for users to identify images.

Property	Description	Example values
`os_type`	The operating system type. Influences hypervisor behaviour such as swap partition format and hostname length limits.	`linux`, `windows`
`os_distro`	The common name of the distribution in lowercase.	`ubuntu`, `debian`, `centos`, `rocky`, `almalinux`, `windows`
`os_version`	The operating system version as specified by the distributor.	`22.04`, `9`, `11`
`os_admin_user`	The default user with admin privileges. Defaults to `root` for Linux and `Administrator` for Windows.	`ubuntu`, `debian`, `root`

openstack image set \
  --property os_type=linux \
  --property os_distro=ubuntu \
  --property os_version=22.04 \
  --property os_admin_user=ubuntu \
  <image-id>

Disk, network, and display hardware

These properties control how virtual disk, network, and display devices are presented to the instance. Using virtio drivers generally provides the best performance.

Property	Description	Example values
`hw_disk_bus`	The type of disk controller to attach disk devices to. We recommend `scsi` for best performance and compatibility with our volume service	`scsi`, `virtio`, `ide`
`hw_scsi_model`	Enables the VirtIO SCSI controller for block device access.	`virtio-scsi`
`hw_vif_model`	The model of the virtual network interface. `virtio` is recommended for best performance.	`virtio`, `e1000`, `e1000e`
`hw_video_model`	The graphic device model presented to the guest. Set to `none` for headless servers.	`virtio`, `vga`, `cirrus`, `qxl`, `none`

openstack image set \
  --property hw_disk_bus=virtio \
  --property hw_vif_model=virtio \
  <image-id>

CPU topology

These properties define the preferred virtual CPU topology for the instance. This is useful for performance-sensitive workloads such as NUMA-aware applications or software licensed per socket.

Property	Description	Example values
`hw_cpu_sockets`	Preferred number of CPU sockets.	`1`, `2`, `4`
`hw_cpu_cores`	Preferred number of cores per socket.	`2`, `4`, `8`
`hw_cpu_threads`	Preferred number of threads per core.	`1`, `2`

openstack image set \
  --property hw_cpu_sockets=1 \
  --property hw_cpu_cores=4 \
  --property hw_cpu_threads=2 \
  <image-id>

Firmware and boot

Property	Description	Example values
`hw_firmware_type`	The firmware type used to boot the guest. Use `uefi` for images that require UEFI boot.	`bios`, `uefi`
`hw_machine_type`	The machine type, mainly relevant for ARM architectures (default `virt`) or Hyper-V generations.	`virt`, `hyperv-gen2`
`os_secure_boot`	Require Secure Boot when booting the instance. The image must be signed and `hw_firmware_type` must be `uefi`.	`required`, `disabled`

# Example: mark an image as UEFI-boot
openstack image set --property hw_firmware_type=uefi <image-id>

Guest agent and operational behaviour

Property	Description	Example values
`hw_qemu_guest_agent`	Enables the QEMU Guest Agent, which allows the host to interact with the guest OS (e.g. for filesystem quiescing during snapshots). The agent must be installed inside the image.	`yes`, `no`
`hw_rng_model`	Attaches a random-number generator device to the instance, improving entropy for cryptographic operations.	`virtio`
`os_shutdown_timeout`	Time in seconds the compute service waits for a graceful OS shutdown before forcing a power-off.	`60` (default), `0` (immediate)

openstack image set \
  --property hw_qemu_guest_agent=yes \
  --property hw_rng_model=virtio \
  --property os_shutdown_timeout=120 \
  <image-id>

Tip

For a complete reference of all available image properties, see the official OpenStack Glance documentation.

Available public images

The images can be retrieved by executing

$~: openstack image list --tag "managed_by_firstcolo"

+--------------------------------------+----------------------------------+--------+
| ID                                   | Name                             | Status |
+--------------------------------------+----------------------------------+--------+
| ed8722c2-6849-4ff2-a59b-aba733b2bcdf | AlmaLinux 8                      | active |
| f14e6c1e-42e1-4ae4-9271-99aba6362134 | AlmaLinux 9                      | active |
| 01de058b-5059-4d96-bf24-cd16dd81f469 | CentOS Stream 8                  | active |
| c0cf17fc-9b2f-4ea0-b937-7aaaa32eb714 | CentOS Stream 9                  | active |
| 61439960-9f66-4ad6-82b0-8cf4dbd912af | Cirros 0.6.0                     | active |
| 657ac9af-f29d-4538-9d8c-02a88778d1da | Cirros 0.6.1                     | active |
| 053f9c34-4eea-47ea-9694-beafbb80e9bc | Clear Linux 38700                | active |
| 4fa48cce-a5b0-48b2-ad53-658a095962b7 | Debian 10                        | active |
| df9c57c7-ed24-49dc-90e1-036edd7e0419 | Debian 11                        | active |
| 93b5f465-54e1-46da-ba94-c3465adfe048 | Flatcar Container Linux 3227.2.4 | active |
| 551a50dc-276e-40c7-a46d-a0f2c8eeb063 | OPNsense 23.1                    | active |
| 8b33ce93-beb3-4849-b1e6-8c10c4049545 | Rocky 8                          | active |
| 38baa6f5-1520-45b0-b888-a353b8ab76c0 | Rocky 9                          | active |
| b744ac7b-117c-49f1-aa88-585d198b4d78 | Ubuntu 16.04                     | active |
| 183d42bd-f399-4c0f-b826-c47b1dcf6417 | Ubuntu 16.04 Minimal             | active |
| 4b09fc30-028e-4343-9b41-68eccbbf6a6e | Ubuntu 18.04                     | active |
| 226ec551-9a22-412e-be9e-3e5c79be1195 | Ubuntu 18.04 Minimal             | active |
| 54d286d0-b823-472a-b433-5f06e7e0280e | Ubuntu 20.04                     | active |
| 5c9c1e60-bb3e-4e23-84db-6d2ef290280f | Ubuntu 20.04 Minimal             | active |
| 180858f6-6655-444e-8cfd-a9f5f5637aae | Ubuntu 22.04                     | active |
| ae56f6e2-7307-4cd4-9a36-0c242a65005b | Ubuntu 22.04 Minimal             | active |
| 5d5ccb05-8fa2-42bd-a1f0-3f240f4ba9c2 | openSUSE Leap 15.4               | active |
+--------------------------------------+----------------------------------+--------+

Public image lifecycle

Note

The current update cycle is once per month

As soon as we upload a new version of an operating system image the latest version of the currently available image in the cloud will be renamed to the name of the image plus the build date.

For example

Ubuntu 22.04 will be renamed to -> Ubuntu 22.04 (20230413)

The new latest version of an image will always have the full name of the image without any build date in the name

$~: openstack image list --tag "managed_by_firstcolo" |grep "Ubuntu 22.04"
| Ubuntu 22.04                     | active | <---- Latest version
| Ubuntu 22.04 (20230405)          | active |
| Ubuntu 22.04 (20230510)          | active |

Warning

If you want to ensure your application always uses the same image build date make sure to use the id of the image when spawning new instances since the id of the image will not change.

Uploading images

Image sources

If you prefer maintaining your own set of images, this table shows sources for commonly used images suitable for OpenStack:

Distro	URL
CentOS 7	`https://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2`
CentOS 8 Stream	`https://cloud.centos.org/centos/8-stream/x86_64/images/`
Debian 9 (Stretch)	`https://cdimage.debian.org/cdimage/openstack/current-9/debian-9-openstack-amd64.qcow2`
Debian 10 (Buster)	`https://cdimage.debian.org/cdimage/openstack/current-10/debian-10-openstack-amd64.qcow2`
Debian 11 (Bullseye)	`https://cloud.debian.org/images/cloud/bullseye/latest/debian-11-generic-amd64.qcow2`
Flatcar Stable	`https://stable.release.flatcar-linux.net/amd64-usr/current/flatcar_production_openstack_image.img.bz2`
Ubuntu 18.04 LTS (Bionic)	`http://cloud-images.ubuntu.com/bionic/current/bionic-server-cloudimg-amd64.img`
Ubuntu 20.04 LTS (Focal)	`http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64.img`
Ubuntu 22.04 LTS (Jammy)	`https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64.img`

How to upload images?

The "Upload Images" how-to guide explains how to upload images via CLI and GUI.

How to fix Image Verification Errors?

In some cases, custom images can't be used to create volumes because of a missing signature. This usually happens, if the image was created from a volume beforehand. The error message looks like this:

Glance metadata cannot be updated, key signature_verified exists for volume

This can be fixed by removing the signature_verified image property, which may was automatically set during upload:

openstack image unset --property signature_verified <image-id>