Bug #5172
Incorrect SIZE on qcow2 images from remote sources
Status: | Closed | Start date: | 05/29/2017 | |
---|---|---|---|---|
Priority: | Normal | Due date: | ||
Assignee: | - | % Done: | 0% | |
Category: | Core & System | |||
Target version: | Release 5.4.1 | |||
Resolution: | Pull request: | |||
Affected Versions: | OpenNebula 5.2 |
Description
When a qcow2 (or any other non-raw image) is downloaded from a remote source, its SIZE is determined from Content-Length. This leads to incorrect SIZE attributes on IMAGEs and breaks resizing. Users are often unknowingly trying to shrink the image (which is not supported by qemu-img).
In `datastore_mad/remotes/libfs.sh`, I can see:
http://*|https://*) HEADERS=`curl -LIk --max-time 60 $1 2>&1` if echo "$HEADERS" | grep -i -q "OpenNebula-AppMarket-Size"; then # An AppMarket/Marketplace URL SIZE=$(echo "$HEADERS" | grep -i "^OpenNebula-AppMarket-Size:" | tail -n1 | cut -d: -f2) else # Not an AppMarket/Marketplace URL SIZE=$(echo "$HEADERS" | grep -i "^Content-Length:" | tail -n1 | cut -d: -f2) fi error=$? ;;
Does this mean that you are using a workaround for OpenNebula Marketplace and setting the correct size without looking at the actual file size?
Are there any plans for getting SIZE after the file is downloaded or, at least, exposing a way to refresh this information later (on registered IMAGEs)?
Associated revisions
History
#1 Updated by Ruben Diez Lazaro about 4 years ago
This bug also affects to our infrastructure. For some users, the system try to shrink the disks images, so the VM fails to be created.
#2 Updated by Ruben S. Montero almost 4 years ago
- Status changed from Pending to Closed
- Target version set to Release 5.4.1