Skip to main content
IMHCloud Logo
Back to support home

Converting Images to Volumes in OpenStack

StorageCompute

Why Convert Images to Volumes

Converting an image to a volume before launching an instance provides two significant advantages in OpenStack. First, it gives you persistent root storage that survives instance deletion. Second, it allows you to launch multiple instances from the same pre-created volume, reducing deployment time since the image data is already written to block storage.

When you launch an instance directly from an image, OpenStack creates an ephemeral disk. Any changes to that disk disappear if you delete the instance. Converting the image to a volume first means your root disk persists independently, which is essential for production workloads where data retention matters.

Understanding Bootable Volumes

A bootable volume is simply a Cinder volume that contains a complete operating system image. It behaves exactly like a regular volume except it can serve as the root disk when launching an instance. The operating system, kernel, and boot loader are all contained in the volume, allowing it to function as the primary boot device.

This approach separates compute resources from storage resources. You can delete and recreate instances without affecting the root disk, enabling patterns like instance resizing, host migrations, and disaster recovery scenarios where you need to preserve the exact system state.

Creating a Volume from an Image via Horizon Dashboard

The Horizon dashboard provides the most straightforward method for converting images to volumes.

Navigate to Project > Volumes > Volumes in the Horizon interface. Click the Create Volume button in the upper right corner.

In the Volume Source dropdown, select Image. A new dropdown appears showing all available images in your project. Select the image you want to convert.

Set the volume size equal to or larger than the image size. The interface displays the minimum required size. Most standard images require 8GB to 20GB depending on the operating system.

Mark the volume as bootable by leaving the default setting or explicitly checking the bootable option if visible in your OpenStack version. Give the volume a descriptive name like "Ubuntu-22.04-boot" so you can identify it later.

Click Create Volume. The dashboard shows the volume status as "Creating" then "Available" when ready. This process typically takes 30 seconds to 2 minutes depending on image size and storage backend performance.

Creating a Volume from an Image via OpenStack CLI

The command-line interface offers more control and scriptability for image to volume conversion.

First, identify the image you want to convert:

1openstack image list

Note the image ID or name from the output. Then create the volume:

1openstack volume create \
2  --image IMAGE_ID_OR_NAME \
3  --size 20 \
4  --bootable \
5  --description "Bootable Ubuntu 22.04 volume" \
6  ubuntu-boot-vol

Replace IMAGE_ID_OR_NAME with your actual image identifier. The size value is in gigabytes and must meet or exceed the image size requirement.

Check the volume creation status:

1openstack volume list

Look for your newly created volume in the output. The Status column shows "creating" during the conversion process and changes to "available" when complete.

Launching an Instance from a Bootable Volume

Once you have a bootable volume, you can launch instances directly from it.

In Horizon, navigate to Project > Compute > Instances and click Launch Instance. On the Source tab, change the Select Boot Source dropdown to Volume. Your bootable volume appears in the available volumes list. Click the up arrow next to your volume to move it to the Allocated list.

Important: uncheck the Delete Volume on Instance Delete option unless you specifically want the volume removed when the instance terminates. Leaving this unchecked preserves your data and allows volume reuse.

Complete the remaining instance configuration (flavor, networks, security groups) as normal and click Launch Instance.

Via CLI, the process is similar:

1openstack server create \
2  --flavor m1.medium \
3  --volume VOLUME_ID \
4  --network NETWORK_ID \
5  --security-group default \
6  my-instance

Replace VOLUME_ID with your bootable volume ID and NETWORK_ID with your network identifier. The instance boots directly from the volume.

Volume-Backed vs Image-Backed Instances

Understanding the differences between these two approaches helps you choose the right method for each workload.

Image-backed instances use ephemeral storage for the root disk. This storage exists only for the instance lifetime. When you delete the instance, all data on the root disk disappears. These work well for stateless applications, development environments, and workloads where you manage data persistence through external volumes or object storage.

Volume-backed instances store the root disk on a Cinder volume. The volume persists after instance deletion unless explicitly configured otherwise. This approach suits production databases, application servers with local state, and any system where you need to preserve the root filesystem across instance lifecycle events.

Volume-backed instances also enable snapshots of the entire boot volume, creating point-in-time backups of the complete system state including OS configuration and application data.

Performance Considerations

Storage backend type significantly affects volume-backed instance performance. Solid-state storage provides faster boot times and lower I/O latency compared to spinning disks. The impact becomes noticeable with I/O-intensive workloads like databases or high-transaction applications.

Initial volume creation from an image takes longer than spinning up an ephemeral disk. However, this is a one-time cost. Once created, the bootable volume can launch multiple instances with performance identical to the storage backend capability.

Network-attached storage introduces slight latency compared to local ephemeral disks on the compute host. For most applications, this latency is negligible. If you require absolute minimum latency, consider using flavors with local SSD ephemeral storage instead.

Common Use Cases

Persistent development environments benefit from volume-backed instances. Developers can delete instances to save compute costs while preserving their complete development environment on the volume. Relaunching later restores the exact environment state.

Production database servers almost always use volume-backed instances. The persistent root disk ensures database configurations and system-level optimizations survive maintenance operations and instance migrations.

Template-based deployments work well with bootable volumes. Create a fully configured volume once, then launch multiple instances from it. Each instance starts with identical software and configuration, ensuring consistency across your infrastructure.

Disaster recovery scenarios benefit from bootable volume snapshots. Taking regular snapshots of volume-backed instances creates restore points. In a failure scenario, you can create a new instance from the snapshot, recovering the complete system state.

Troubleshooting Volume Creation

If volume creation fails or hangs in "Creating" status, first check quota limits:

1openstack quota show

Verify you have available capacity in gigabytes and volumes. If quotas are exhausted, request an increase or delete unused volumes.

For "Error" status volumes, examine the volume details:

1openstack volume show VOLUME_ID

The output includes fault messages explaining the failure. Common issues include insufficient backend storage capacity, image corruption, or permission problems accessing the image.

If a volume creates successfully but fails to boot, verify the bootable flag:

1openstack volume set --bootable VOLUME_ID

This command explicitly marks the volume as bootable, resolving cases where the flag was not set during creation.

Volume Cloning for Faster Deployments

After creating your first bootable volume, you can clone it instead of converting from the image again. This approach is faster since it copies block data directly without intermediate image format conversion.

1openstack volume create \
2  --source EXISTING_VOLUME_ID \
3  --size 20 \
4  cloned-boot-vol

This creates a new bootable volume as an exact copy of the source volume. Use this technique when you need multiple identical boot volumes for horizontal scaling scenarios.

Best Practices

Always size bootable volumes larger than the minimum image requirement. This provides space for system updates, application data, and log files without running out of disk space. A 20GB to 50GB volume works well for most general-purpose workloads.

Use descriptive volume names that indicate the contained OS and purpose. Examples: "ubuntu-22-web-server" or "centos-9-database-prod". This naming prevents confusion when you manage dozens of volumes.

Tag bootable volumes with metadata to track image source and creation date:

1openstack volume set \
2  --property source_image=IMAGE_ID \
3  --property created_date=2026-01-29 \
4  VOLUME_ID

These properties help with compliance auditing and image lifecycle management.

Enable volume backups for critical bootable volumes. OpenStack's volume backup service creates compressed backups stored in object storage, providing protection against storage backend failures.

Image Updates and Volume Management

When upstream OS vendors release updated images, you face a choice. You can create new bootable volumes from the updated image or update existing volumes in place.

Creating new volumes from updated images is the cleaner approach. Launch new instances from the fresh volumes, migrate application data, then decommission old instances. This method ensures you capture all OS-level changes and security patches included in the new image.

In-place updates require connecting to running instances and performing standard OS updates. This works but may miss image-level optimizations or driver updates that only exist in the new image.

For production systems, maintain a volume replacement schedule aligned with your image update cycle. Most organizations refresh bootable volumes quarterly or when critical security updates require it.

Related Resources

For more information on OpenStack storage and instance management, see these official resources: