Editing Image Properties and Metadata in OpenStack

Understanding Image Properties and Metadata in OpenStack

In OpenStack, images managed by the Glance service contain more than just boot disk data. They carry metadata that controls visibility, compatibility, and access control across your cloud environment. Properly managing image properties ensures efficient resource usage, proper access control, and smooth instance deployment across multi-tenant environments.

Image metadata serves several critical functions. It defines hardware requirements, controls who can access the image, specifies boot behavior, and enables proper resource allocation. Whether you're managing a single project or multiple tenants, understanding how to edit and control these properties is fundamental to cloud administration.

Common Image Properties You Can Edit

OpenStack images support both standard and custom properties that control behavior and access.

Standard Properties:

Visibility and Access Control:

• visibility defines who can see and use the image (public, private, shared, community)
• protected prevents accidental deletion when set to true
• owner identifies the project that owns the image

Hardware and Performance:

• min_ram sets the minimum RAM required to boot the instance
• min_disk defines the minimum disk size needed
• architecture specifies the CPU architecture (x86_64, arm64)

Boot Behavior:

• hw_disk_bus defines the disk interface type (virtio, scsi, ide)
• hw_vif_model sets the network interface model
• os_type identifies the operating system (linux, windows)

Custom Properties:

You can add custom key-value pairs for organizational purposes, automation workflows, or integration with external systems. Examples include department tags, compliance labels, or application identifiers.

Viewing Current Image Properties

Before editing properties, review the current metadata to understand what you're working with.

Using OpenStack CLI:

1openstack image show <image-id>
Copy

This command displays all properties, including visibility, protection status, size, and custom metadata.

Using Horizon Dashboard:

1. Navigate to Project > Compute > Images
2. Click on the image name
3. Select the Overview tab to view all properties and metadata

The output shows standard properties at the top level and custom properties under the properties field.

How to Edit Image Properties in Horizon Dashboard

The Horizon dashboard provides a graphical interface for editing image properties without using the command line. This section covers all common property management tasks through the web interface.

Accessing the Images Panel

Before editing any properties, navigate to the images management interface:

1. Log into the Horizon dashboard at your OpenStack cloud URL
2. Navigate to Project > Compute > Images
3. The images table displays all images visible to your project
4. Locate the image you want to modify in the list

Each image row shows the name, type, status, visibility, protected status, disk format, and size. The Actions column provides a dropdown menu with available operations.

Editing Basic Image Properties

The Edit Image dialog lets you modify core properties like name, description, hardware requirements, and visibility.

Step-by-step process:

1. In the images table, click the dropdown arrow in the Actions column for your target image
2. Select Edit Image from the menu
3. The Edit Image dialog opens with multiple sections

Modifying the Image Name:

1. In the Name field, enter a new descriptive name
2. Use consistent naming conventions like ubuntu-22.04-base-2026-01-15
3. Avoid special characters that could cause issues in automation scripts

Updating the Description:

1. In the Description field, add or modify the text
2. Include relevant information like OS version, installed software, or configuration details
3. This description appears in instance launch wizards and helps users select appropriate images

Setting Minimum Disk Requirements:

1. Locate the Minimum Disk (GB) field
2. Enter the minimum root disk size in gigabytes
3. This prevents users from launching instances with insufficient disk space
4. Set this based on the actual space consumed by the OS and pre-installed applications

Setting Minimum RAM Requirements:

1. Locate the Minimum RAM (MB) field
2. Enter the minimum memory requirement in megabytes
3. This ensures instances have enough RAM to run the operating system and applications properly
4. Consider the base OS requirements plus any pre-installed services

Specifying the Disk Format:

1. In the Format dropdown, select the appropriate disk format
2. Common formats include QCOW2, RAW, VMDK, VDI, or ISO
3. QCOW2 is recommended for most cloud images due to copy-on-write support and smaller size

Setting the Container Format:

1. In the Container Format dropdown, choose the appropriate option
2. Most cloud images use bare (no container format)
3. Other options include AMI, ARI, AKI, OVF, or OVA

Defining the Kernel and Ramdisk:

1. If using AMI images, select the appropriate Kernel and Ramdisk from the dropdowns
2. For most modern cloud images, leave these empty as the kernel is included in the image

Setting the Architecture:

1. In the Architecture dropdown, select the CPU architecture
2. Common options include x86_64 (most common), i686, arm64, or others
3. This helps the scheduler place instances on compatible compute nodes

Saving Your Changes:

1. After making all modifications, click Update Image at the bottom of the dialog
2. Horizon validates the input and saves the changes
3. A success notification appears if the update completes successfully
4. The updated properties immediately appear in the images table

Changing Image Visibility

Image visibility controls which users and projects can see and use an image. The Edit Image dialog provides visibility options based on your permissions.

Understanding Visibility Options:

The Visibility dropdown in the Edit Image dialog offers several options:

Public: All users across all projects can see and use the image. This option is only available to administrators with appropriate permissions. Use this for base operating system images that should be widely available.

Private: Only the owner project can see and use the image. This is the default for newly created images. Use this for proprietary applications, customized configurations, or sensitive data.

Shared: The image owner explicitly grants access to specific projects. Other projects cannot see the image unless added to the member list. This option requires additional configuration through the Update Members dialog.

Community: All users can see the image, but only the owner can modify it. Unlike public images, community images don't require administrator privileges. Use this for user-contributed templates or experimental images.

Changing Visibility Step-by-Step:

1. Click the dropdown arrow in the Actions column for your image
2. Select Edit Image
3. Locate the Visibility dropdown in the dialog
4. Select your desired visibility level from the available options
5. Click Update Image to save the change
6. Horizon applies the new visibility setting immediately

Important Notes:

If you select Private or Community visibility, any existing member access is revoked. Projects that previously had access through sharing will lose it.

If you select Shared visibility, the image becomes private to your project by default. You must then add specific projects as members through the Update Members interface.

Only administrators can set images to Public visibility. If this option is grayed out or unavailable, contact your cloud administrator.

Managing Shared Image Access

Shared images provide granular access control for multi-tenant environments. The Update Members dialog lets you grant and revoke access for specific projects.

Setting an Image to Shared Visibility:

1. Click the dropdown arrow in the Actions column for your image
2. Select Edit Image
3. Change Visibility to Shared
4. Click Update Image
5. The image is now in shared mode but has no members yet

Adding Project Members:

1. Return to the images table
2. Click the dropdown arrow for your shared image
3. Select Update Members from the menu
4. The Update Image Members dialog opens with two columns

Understanding the Members Interface:

The left column shows All Projects that can be added as members. The right column shows Image Members that currently have access.

Granting Access to a Project:

1. In the All Projects column, locate the project you want to grant access to
2. You can filter projects using the search box at the top
3. Click the + button next to the project name
4. The project moves from All Projects to Image Members
5. The change takes effect immediately

Adding Multiple Projects:

1. Repeat the process for each project that needs access
2. You can add as many projects as needed
3. Each project appears in the Image Members column with its name and ID

Removing Project Access:

1. In the Image Members column, locate the project you want to remove
2. Click the - button next to the project name
3. The project moves back to All Projects
4. That project immediately loses access to the image

Saving Changes:

1. After adding or removing all members, click Save at the bottom of the dialog
2. Horizon confirms the changes
3. A success notification appears

Accepting Shared Images (Target Project):

When a project receives shared image access, a user from that project must accept it:

1. Log into Horizon as a user in the target project
2. Navigate to Project > Compute > Images
3. The shared image appears in the table with a Pending status in the member column
4. Click the dropdown arrow for the shared image
5. Select Accept Image from the menu
6. The image status changes to Accepted
7. The project can now use this image to launch instances

Adding Custom Properties

Custom properties enable tagging, automation, and integration with external systems. Horizon provides a metadata interface for adding key-value pairs.

Accessing the Metadata Editor:

1. In the images table, click the dropdown arrow for your image
2. Select Update Metadata from the menu
3. The Update Image Metadata dialog opens with available and existing metadata

Understanding the Metadata Interface:

The dialog shows two sections:

Existing Metadata: Displays properties already assigned to this image, including both standard properties set through other interfaces and custom properties you've added.

Available Metadata: Shows predefined metadata keys that Horizon recognizes. These include common properties like architecture, hw_disk_bus, hw_vif_model, and os_type.

Adding Predefined Metadata:

1. In the Available Metadata section on the left, locate the property you want to add
2. Click the + button next to the property name
3. The property moves to Existing Metadata on the right
4. Enter the appropriate value in the field next to the property name
5. Click Save when finished

Examples of predefined properties:

architecture: Set to x86_64, arm64, i686, or other CPU architectures

hw_disk_bus: Set to virtio, scsi, ide, or usb to define the disk interface type

hw_vif_model: Set to virtio, e1000, rtl8139, or other network interface models

os_type: Set to linux or windows to identify the operating system

Adding Custom Properties:

1. In the Custom section at the bottom of the dialog, click the + button
2. A new row appears with empty Key and Value fields
3. In the Key field, enter your custom property name (use lowercase with underscores or hyphens)
4. In the Value field, enter the property value
5. Click the + button again to add additional custom properties
6. Click Save when all properties are added

Example Custom Properties:

department: engineering - Track which team owns this image

application: wordpress - Identify the primary application installed

version: 6.4 - Tag application or OS versions for automation

compliance: pci-dss - Mark images meeting specific regulatory requirements

environment: production - Distinguish between production and test images

cost_center: cc-1234 - Tag for chargeback reporting

Removing Custom Properties:

1. In the Existing Metadata section, locate the property you want to remove
2. Click the - button next to the property
3. The property is removed from the image
4. Click Save to confirm the removal

Best Practices for Custom Metadata:

Use consistent naming conventions across your organization. Establish a documented list of approved custom property keys and their meanings. This prevents teams from creating redundant or conflicting metadata schemas.

Protecting Images from Deletion

Protected images cannot be deleted, even by administrators. This prevents accidental removal of critical base images or compliance-required templates.

Enabling Image Protection:

1. In the images table, click the dropdown arrow for your image
2. Select Edit Image
3. Locate the Protected checkbox in the dialog
4. Check the box to enable protection
5. Click Update Image
6. The image now shows Yes in the Protected column of the images table

Disabling Image Protection:

1. Click the dropdown arrow for your protected image
2. Select Edit Image
3. Uncheck the Protected checkbox
4. Click Update Image
5. The image protection is removed

What Protection Prevents:

When an image is protected, any deletion attempt returns an error through both Horizon and the CLI. This applies to all users, including administrators. The protection must be explicitly removed before deletion can proceed.

When to Use Protection:

Enable protection for production base images that multiple teams rely on. Protect images that meet compliance requirements and must be retained. Protect golden images that serve as templates for standardized deployments.

Verification:

After enabling or disabling protection, verify the status by checking the Protected column in the images table. The value should reflect your intended setting.

How to Edit Image Properties Using OpenStack CLI

The OpenStack command line interface provides powerful tools for editing image properties programmatically. This section covers all property management operations using the CLI.

Changing Image Visibility Using CLI

Image visibility controls which users and projects can access an image. The CLI provides straightforward commands for changing visibility settings.

Understanding Visibility Options:

Public: All users across all projects can see and use the image. Only administrators can set images to public visibility. Use this for base operating system images or widely-used templates.

Private: Only the owner project can see and use the image. This is the default for newly created images. Use this for proprietary applications or sensitive configurations.

Shared: The image owner explicitly grants access to specific projects. Other projects cannot see the image unless added to the member list. Use this for controlled sharing between departments or partner organizations.

Community: All users can see the image, but only the owner can modify it. Unlike public images, community images don't require administrator privileges to create. Use this for user-contributed templates or experimental images.

Commands for Changing Visibility:

1. Set an image to private visibility:

1openstack image set --private <image-id>
Copy

2. Set an image to public visibility (requires administrator privileges):

1openstack image set --public <image-id>
Copy

3. Set an image to community visibility:

1openstack image set --community <image-id>
Copy

4. Set an image to shared visibility:

1openstack image set --shared <image-id>
Copy

For shared visibility, you must add specific projects as members after setting the image to shared status. This is covered in the next section.

Managing Shared Image Access Using CLI

Shared images provide granular access control for multi-tenant environments. You explicitly define which projects can access the image.

Setting an Image to Shared:

1. First, change the image visibility to shared:

1openstack image set --shared <image-id>
Copy

This makes the image private by default with no members. You must then add projects as members.

Adding Project Members:

2. Grant access to a specific project:

1openstack image add project <image-id> <project-id>
Copy

Replace <project-id> with the UUID of the target project. You can find project IDs using openstack project list.

3. The target project must accept the shared image before they can use it:

1openstack image set --accept <image-id>
Copy

Run this command while authenticated as a user in the target project. Until accepted, the image appears with a pending status.

Viewing Image Members:

4. List all projects that have been granted access:

1openstack image member list <image-id>
Copy

This displays all project members along with their acceptance status (pending or accepted).

Removing Project Access:

5. Revoke access from a specific project:

1openstack image remove project <image-id> <project-id>
Copy

The project immediately loses access to the image.

This workflow gives you complete control over image distribution across your cloud environment without making images globally available.

Adding Custom Properties Using CLI

Custom properties enable tagging, automation, and integration with external systems. The CLI makes it easy to add key-value metadata to images.

Adding a Single Property:

1. Add one custom property to an image:

1openstack image set --property department=engineering <image-id>
Copy

The property key is department and the value is engineering. Use this pattern for any custom metadata.

Adding Multiple Properties:

2. Add several custom properties in a single command:

1openstack image set \
2  --property application=wordpress \
3  --property version=6.4 \
4  --property compliance=pci-dss \
5  <image-id>
Copy

Each --property flag adds one key-value pair. This is more efficient than running multiple separate commands.

Use Cases for Custom Properties:

Organizational tagging: Track which department or team owns the image. Example: --property department=engineering

Version management: Identify application versions without parsing the image name. Example: --property version=6.4

Compliance tracking: Mark images that meet specific regulatory requirements. Example: --property compliance=pci-dss

Automation integration: Pass metadata to orchestration tools like Terraform or Ansible. Example: --property terraform_managed=true

Cost allocation: Tag images for chargeback reporting. Example: --property cost_center=cc-1234

Custom properties appear in the image details and can be queried for automation workflows. Use consistent naming conventions across your organization for best results.

Modifying Hardware Requirements Using CLI

Hardware properties ensure instances have sufficient resources and use compatible interfaces. The CLI provides commands to set minimum requirements and architecture specifications.

Setting Minimum RAM:

1. Define the minimum RAM required to boot instances from this image:

1openstack image set --min-ram 2048 <image-id>
Copy

This prevents users from launching instances with insufficient memory. Specify the value in megabytes. For example, 2048 equals 2GB of RAM.

Setting Minimum Disk:

2. Define the minimum root disk size needed:

1openstack image set --min-disk 20 <image-id>
Copy

This ensures the root disk has enough space for the operating system and applications. Specify the value in gigabytes. For example, 20 equals 20GB of disk space.

Setting Architecture:

3. Specify the CPU architecture for this image:

1openstack image set --property architecture=x86_64 <image-id>
Copy

Common values include x86_64 (most common), arm64, i686, or other architectures. This helps schedulers place instances on compatible compute nodes.

Setting Disk Bus Type:

4. Define the disk interface type for better performance:

1openstack image set --property hw_disk_bus=virtio <image-id>
Copy

Common options include virtio (recommended for performance), scsi, ide, or usb.

Setting Network Interface Model:

5. Specify the network interface model:

1openstack image set --property hw_vif_model=virtio <image-id>
Copy

Options include virtio (recommended), e1000, rtl8139, or others supported by your hypervisor.

These constraints prevent deployment failures and improve the user experience by blocking incompatible configurations at launch time.

Removing Properties Using CLI

You can remove custom properties if they're no longer needed or contain incorrect information.

Removing a Single Property:

1. Remove one custom property from an image:

1openstack image unset --property department <image-id>
Copy

Specify the property key without the value. The property is completely removed from the image.

Removing Multiple Properties:

2. Remove several properties in a single command:

1openstack image unset \
2  --property application \
3  --property version \
4  <image-id>
Copy

Each --property flag removes one key-value pair.

Important Notes:

Standard properties like min_ram and min_disk can be updated but not fully removed using the unset command. To effectively disable these constraints, set them to 0:

1openstack image set --min-ram 0 <image-id>
2openstack image set --min-disk 0 <image-id>
Copy

Protecting Images from Deletion Using CLI

Protected images cannot be deleted, even by administrators. This prevents accidental removal of critical base images or compliance-required templates.

Enabling Protection:

1. Enable deletion protection for an image:

1openstack image set --protected <image-id>
Copy

Once protected, any deletion attempt returns an error until protection is explicitly removed. This adds a safety layer for production environments.

Disabling Protection:

2. Remove deletion protection when you need to delete an image:

1openstack image set --unprotected <image-id>
Copy

After removing protection, the image can be deleted normally.

Verification:

3. Check if an image is protected:

1openstack image show <image-id> -c protected
Copy

This displays only the protected status. The value is either True or False.

When to Use Protection:

Enable protection for production base images that multiple teams rely on. Protect images that meet compliance requirements and must be retained. Protect golden images that serve as templates for standardized deployments.

Once protected, any deletion attempt returns an error until protection is explicitly removed. This adds a safety layer for production environments where accidental deletions could cause widespread disruption.

Bulk Property Updates Across Multiple Images

When managing large image libraries, you may need to apply properties to multiple images at once.

Using Shell Loops:

1for image in $(openstack image list --private -f value -c ID); do
2  openstack image set --property environment=production $image
3done
Copy

Using Filtering:

1openstack image list --property department=engineering -f value -c ID | \
2  xargs -I {} openstack image set --property compliance=reviewed {}
Copy

This approach is valuable during organizational changes, compliance audits, or when implementing new tagging standards across your cloud environment.

Best Practices for Image Metadata Management

Establish Naming Conventions: Use consistent, descriptive names that include OS, version, and date. Example: ubuntu-22.04-base-2026-01-15.

Document Custom Properties: Maintain a centralized list of approved custom property keys and their meanings. This prevents inconsistent tagging across teams.

Use Visibility Appropriately: Default to private visibility and explicitly share when needed. Avoid public images unless they're truly intended for all users.

Protect Production Images: Enable protection on all images used in production workloads to prevent accidental deletion.

Regular Metadata Audits: Periodically review image properties to remove obsolete tags and ensure accuracy.

Version Control: Include version information in custom properties for applications and operating systems. This enables automated tooling to select appropriate images.

Test Before Deployment: Modify properties on test images first to verify behavior before applying changes to production images.

Troubleshooting Common Issues

Cannot Change Visibility to Public:

Only administrators with appropriate role assignments can set images to public visibility. If you need public images, contact your cloud administrator or use community visibility instead.

Image Member Status Shows Pending:

The target project must explicitly accept shared images before they can use them. Run openstack image set --accept <image-id> from the target project.

Cannot Delete Image:

If the image is protected, you'll receive an error. Remove protection first with openstack image set --unprotected <image-id>, then attempt deletion.

Custom Properties Not Appearing:

Ensure you're using the correct syntax with --property key=value. Properties with spaces in values should be quoted: --property "description=Test image".

Minimum RAM/Disk Not Enforced:

If users can still launch instances below the minimum requirements, verify that the scheduler and Nova configuration properly enforce these constraints. This may require administrator assistance.

Summary

Editing image properties and metadata in OpenStack gives you precise control over image access, compatibility, and organization. Whether you're managing visibility for multi-tenant environments, setting hardware requirements, or adding custom tags for automation, these tools enable efficient cloud operations.

Key capabilities include changing visibility between public, private, shared, and community modes, managing member access for shared images, setting minimum hardware requirements, adding custom properties for organizational needs, protecting critical images from deletion, and using both CLI and dashboard interfaces for property management.

Proper image metadata management improves security through access control, prevents deployment failures with hardware constraints, enables automation through custom tagging, and supports compliance through protection and documentation.