🚨 OpenStack Error Guide: 'ImageUnacceptable' Cinder volume-from-image failure

Exact Error Message

$ openstack volume show vol-bootimg -c status -c error
+--------+----------------------------------------------------------------------+
| Field  | Value                                                                |
+--------+----------------------------------------------------------------------+
| status | error                                                                 |
+--------+----------------------------------------------------------------------+

In the cinder-volume log:

2026-06-27 15:31:07.882 12 ERROR cinder.volume.flows.manager.create_volume
ImageUnacceptable: Image 4f2a... is unacceptable: Image virtual size is 12 GB
and doesn't fit in a volume of size 10 GB.
2026-06-27 15:31:07.882 12 ERROR cinder.volume.flows.manager.create_volume
Traceback (most recent call last):
2026-06-27 15:31:07.882 12 ERROR cinder.volume.flows.manager.create_volume   File
".../cinder/volume/flows/manager/create_volume.py", line 1156, in _create_from_image
2026-06-27 15:31:07.882 12 ERROR cinder.volume.flows.manager.create_volume
raise exception.ImageUnacceptable(...)

What the Error Means

ImageUnacceptable is raised by cinder-volume when it tries to write a Glance image into a new volume and the image does not fit the request. The most common form is a size mismatch: the image’s virtual size (the size of the disk it represents when decompressed) is larger than the requested volume, so the data cannot be written without truncation. Cinder refuses rather than create a corrupt volume.

It is not a Glance download failure or a backend connectivity problem — the image is reachable and valid. The issue is a property mismatch: virtual size exceeds volume size, the disk format is one the backend cannot ingest, or the image’s declared min_disk is larger than the volume. This frequently surfaces during boot-from-volume launches, where Nova asks Cinder to create the root volume from an image and passes a volume size that is too small.

Common Causes

• Image virtual size larger than the volume — a qcow2 image whose virtual disk is 12 GB cannot land in a 10 GB volume.
• min_disk on the image exceeds the requested size — Glance metadata declares a minimum that the volume request violates.
• Wrong disk format for the backend — a backend expecting raw is handed a qcow2/vmdk it cannot convert, or conversion is disabled.
• Boot-from-volume with a default/too-small size — the flavor or launch request supplies a root volume smaller than the image.
• Compressed image virtual size underestimated — operators size by the (small) file size rather than the (large) virtual size.
• Corrupt or wrongly-declared image metadata — disk_format/container_format do not match the actual file.

How to Reproduce the Error

Deterministic reproduction with a size mismatch:

1. Find an image whose virtual size is larger than a round number, e.g. 12 GB.
2. Request a smaller volume from it.

openstack image show <image-id> -c min_disk -c size -c properties
openstack volume create --image <image-id> --size 10 vol-bootimg

Cinder downloads the image, compares virtual size (12 GB) to volume size (10 GB), and fails the volume to error with ImageUnacceptable. A boot-from-volume server with a too-small root size reproduces it via Nova → Cinder.

Diagnostic Commands

Read-only. The goal is to compare the image’s real requirements against the volume request.

# Image metadata: file size, declared min_disk, format
openstack image show <image-id> -c size -c min_disk -c disk_format -c container_format

# The failed volume and what was requested
openstack volume show vol-bootimg -c size -c status -c volume_type -c volume_image_metadata

| disk_format | qcow2 |
| min_disk    | 12    |
| size        | 3489660928 |   # 3.4 GB file, but virtual size can be much larger

Read the cinder-volume log for the exact rejection (it names both sizes):

# Kolla-Ansible
docker logs cinder_volume 2>&1 | grep -i ImageUnacceptable | tail
# Traditional packages
journalctl -u openstack-cinder-volume | grep -i ImageUnacceptable | tail

To confirm the virtual size (not the file size) of a qcow2 you have access to:

qemu-img info /path/to/image.qcow2 | grep -i "virtual size"

Step-by-Step Resolution

1. Read the two numbers from the log. The message states both the image virtual size and the volume size. The fix is almost always to make the volume at least as large as the virtual size.

2. Check the image’s min_disk. If min_disk is 12, no volume below 12 GB will ever succeed:

   openstack image show <image-id> -c min_disk

3. Recreate the volume at a sufficient size — at least the virtual size and at least min_disk:

   openstack volume create --image <image-id> --size 20 vol-bootimg

4. For boot-from-volume launches, set the root volume size explicitly so Nova requests a large enough volume:

   openstack server create \
     --flavor m1.small \
     --block-device-mapping vda=<image-id>:image:20:true \
     --network <net-id> my-vm

5. Fix format mismatches if the backend rejected the format. Confirm the backend supports the image’s disk_format; if it requires raw, ensure Cinder image conversion is enabled or upload a raw image. Check the backend’s expectations against volume_type properties.

6. Correct bad image metadata if min_disk or disk_format was declared wrong — re-register the image with accurate values rather than oversizing every volume to compensate.

Prevention and Best Practices

• Set each image’s min_disk to its true virtual size so launches and volume creates fail fast at request time with a clear message instead of mid-build.
• Size boot-from-volume root disks from the image’s virtual size, never its compressed file size — the two can differ by an order of magnitude.
• Standardize on a disk format your Cinder backends accept; document whether image conversion to raw is enabled.
• Validate new images after upload by checking qemu-img info virtual size against the declared min_disk.
• Alert on Cinder volumes entering error state so an ImageUnacceptable mismatch is caught before it cascades into failed instance launches.

Related Errors

• Image <id> is unacceptable: Image is not raw format — the format variant of the same exception.
• ImageCopyFailure / ImageDownloadFailed — the image could not be fetched at all (a Glance/connectivity problem, not a size mismatch).
• Block Device Mapping is Invalid: Boot sequence for the instance ... — Nova’s wrapper when boot-from-volume sizing is wrong. See our /categories/openstack/ Cinder guides.
• VolumeSizeExceedsAvailableQuota — a quota rejection, not an image-fit rejection.

Frequently Asked Questions

Why does a 3 GB image need a 20 GB volume? Image file size is the compressed on-disk size. Image virtual size is the size of the disk it represents when expanded. A 3 GB qcow2 file can have a 12 GB or larger virtual disk, and the volume must hold the virtual size.

Can I shrink the image instead of growing the volume? You can rebuild a smaller image (smaller virtual disk), but the simplest and safest fix is sizing the volume to at least the image’s virtual size and min_disk.

Where does min_disk come from? It is Glance image metadata set at upload time. It declares the minimum volume/disk required to use the image and is enforced by both Nova and Cinder.

Does boot-from-volume hit this differently? The mechanism is the same — Nova asks Cinder to create the root volume from the image. If the block-device-mapping size is too small, Cinder raises ImageUnacceptable and the launch fails.

Is Kolla-Ansible affected differently? No. The cause and fix are identical; only log access differs (docker logs cinder_volume versus journalctl -u openstack-cinder-volume).