🚨 OpenStack Error Guide: '413 Request Entity Too Large' — Fix Glance Image Upload Rejection

Overview

413 Request Entity Too Large is the HTTP error a Glance image upload returns when some layer in the path decides the image is bigger than an allowed limit and refuses it. The limit can be Glance’s own image_size_cap, a per-user storage quota, or — commonly — an HAProxy/reverse-proxy request-body cap in front of the API that rejects the transfer before Glance even sees it all.

The literal errors you will see:

413 Request Entity Too Large: The body of your request was too large for this server to process.

HTTPException: 413 Request Entity Too Large
Image size caps at 1073741824 bytes and the supplied image is 5368709120 bytes.

It occurs during glance image-create/openstack image create --file ... when uploading image data. The tell is that small images upload fine while large ones fail at a consistent size threshold — pointing at a configured cap rather than a store outage.

Symptoms

• Large image uploads fail with 413; small ones succeed.
• The image lands in queued (never active) or is deleted after the failed upload.
• The failure is reproducible at the same size boundary.

openstack image create --file big.qcow2 --disk-format qcow2 --container-format bare big-image

HTTP 413 Request Entity Too Large

docker logs glance_api 2>&1 | grep -iE "413|too large|image_size_cap|quota" | tail -5

WARNING glance.api ... 413 Request Entity Too Large: Denying attempt to upload image larger than image_size_cap

Common Root Causes

1. Glance image_size_cap too low

Glance enforces a maximum image size; uploads above it are rejected with 413.

docker exec glance_api grep -E '^image_size_cap' /etc/glance/glance-api.conf

image_size_cap = 1073741824

1073741824 is 1 GiB — any larger image is denied. If the log names image_size_cap, this is the cause.

2. Per-user storage quota exceeded

Glance’s user_storage_quota limits total bytes a user may store; exceeding it returns 413.

docker exec glance_api grep -E '^user_storage_quota' /etc/glance/glance-api.conf
openstack image list --property owner=<project-id> -f value -c Name -c Size 2>/dev/null | head

user_storage_quota = 10737418240

If the user’s existing images plus the new one exceed the quota, the upload is refused.

3. HAProxy / reverse-proxy body-size limit

A proxy in front of Glance may cap request body size and return 413 before Glance processes the stream — this is often the surprising real cause.

docker exec haproxy grep -iE 'timeout|maxconn' /etc/haproxy/haproxy.cfg | head
docker logs glance_api 2>&1 | grep -c 413   # if 0 but client got 413, suspect the proxy

# glance_api logged zero 413s but the client saw 413 -> the proxy rejected it

If Glance itself never logs the 413, the proxy or an upstream gateway rejected the body.

4. Web server / WSGI request-size limit

When Glance runs behind Apache/mod_wsgi or a uwsgi front, LimitRequestBody or buffer limits can trigger 413.

docker exec glance_api grep -riE 'LimitRequestBody|client_max_body_size|buffer-size' \
  /etc/glance/ /etc/httpd/ 2>/dev/null | head

LimitRequestBody 2147483648

5. Store out of space (surfaced as a size error)

A full backend store can cause the API to reject large writes; check store capacity when 413 correlates with a nearly-full store.

docker exec glance_api grep -E 'filesystem_store_datadir|^stores|default_backend' \
  /etc/glance/glance-api.conf
df -h /var/lib/glance/images 2>/dev/null

/dev/mapper/glance  100G  100G   0    100% /var/lib/glance/images

Diagnostic Workflow

Step 1: Determine whether Glance or the proxy returned the 413

docker logs glance_api 2>&1 | grep -c 413

Zero here while the client saw 413 means a proxy/web-server limit; a non-zero count means Glance’s own cap or quota.

Step 2: Read Glance’s configured caps

docker exec glance_api grep -E '^image_size_cap|^user_storage_quota' /etc/glance/glance-api.conf

Step 3: Compare the image size to the cap

ls -l big.qcow2   # bytes
# compare against image_size_cap (bytes)

Step 4: Check the proxy body limits

docker exec haproxy grep -iE 'timeout|maxconn' /etc/haproxy/haproxy.cfg
docker exec glance_api grep -riE 'LimitRequestBody|client_max_body_size' /etc/ 2>/dev/null

Step 5: Verify store capacity

df -h /var/lib/glance/images 2>/dev/null
docker exec glance_api grep -E 'default_backend|stores' /etc/glance/glance-api.conf

Example Root Cause Analysis

A team uploading a 5 GiB appliance image gets 413 Request Entity Too Large, while their 800 MiB base images upload fine. The operator first checks whether Glance logged the rejection:

docker logs glance_api 2>&1 | grep 413 | tail -3

WARNING glance.api ... Denying attempt to upload image larger than image_size_cap (1073741824 bytes)

Glance itself rejected it, and the message names image_size_cap. The config confirms the 1 GiB cap:

docker exec glance_api grep '^image_size_cap' /etc/glance/glance-api.conf

image_size_cap = 1073741824

The cap was left at a conservative default. The fix is to raise it to a value that fits the organization’s largest legitimate image (with headroom), via Kolla config override, then reconfigure and retry:

# set image_size_cap = 21474836480 (20 GiB) in the glance-api config override, then:
kolla-ansible reconfigure -t glance
docker exec glance_api grep '^image_size_cap' /etc/glance/glance-api.conf
openstack image create --file big.qcow2 --disk-format qcow2 --container-format bare big-image

image_size_cap = 21474836480
| status | active |

Before raising the cap, confirm the store and user_storage_quota have room for images that large. Longer term, document a sanctioned maximum image size and align the cap, quota, and any proxy body limits to it.

Prevention Best Practices

• Set image_size_cap deliberately to your largest sanctioned image plus headroom — not the default — and document the value.
• Keep user_storage_quota, the store capacity, and image_size_cap consistent so a permitted-size upload can’t fail on quota or disk.
• Align any HAProxy/reverse-proxy and web-server body-size limits with image_size_cap; a proxy 413 is invisible in Glance logs and confuses triage.
• Monitor the Glance store’s free space and alert before it fills, since a full store can surface as upload rejections.
• Prefer image import via the web-download/copy-image flows for very large images to avoid streaming huge bodies through the API and proxy.
• When triaging, always first check whether Glance logged the 413 or the proxy did — it changes which limit you raise.
• Paste the upload error and config into the free incident assistant to pinpoint which layer set the cap, and see more OpenStack guides.

Quick Command Reference

# Did Glance or the proxy return the 413?
docker logs glance_api 2>&1 | grep -c 413

# Glance caps and quota
docker exec glance_api grep -E '^image_size_cap|^user_storage_quota' /etc/glance/glance-api.conf

# Image size vs cap
ls -l big.qcow2

# Proxy / web-server body limits
docker exec haproxy grep -iE 'timeout|maxconn' /etc/haproxy/haproxy.cfg
docker exec glance_api grep -riE 'LimitRequestBody|client_max_body_size' /etc/ 2>/dev/null

# Store capacity
df -h /var/lib/glance/images 2>/dev/null
docker exec glance_api grep -E 'default_backend|stores' /etc/glance/glance-api.conf

# Apply a new cap (after config override)
kolla-ansible reconfigure -t glance

Conclusion

413 Request Entity Too Large on a Glance upload means some layer decided the image exceeds an allowed size. The reproducible size boundary is the diagnostic signature. Typical root causes:

1. image_size_cap set too low for the image.
2. The user’s user_storage_quota is exceeded.
3. An HAProxy/reverse-proxy request-body limit rejecting the transfer before Glance.
4. A web-server/WSGI LimitRequestBody cap.
5. A full backend store surfacing as a size rejection.

Check whether Glance itself logged the 413 first: if it did, raise image_size_cap/quota after confirming store capacity; if it didn’t, the limit lives in the proxy or web server in front of the API.