Bug 1378694 - Prevent qemu-img resize from causing "Active L1 table too large"
Summary: Prevent qemu-img resize from causing "Active L1 table too large"
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Max Reitz
QA Contact: Ping Li
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 1459725
TreeView+ depends on / blocked
 
Reported: 2016-09-23 06:19 UTC by Ping Li
Modified: 2018-03-22 03:27 UTC (History)
18 users (show)

(edit)
Clone Of:
: 1459725 (view as bug list)
(edit)
Last Closed: 2017-08-01 23:37:14 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2017:2392 normal SHIPPED_LIVE Important: qemu-kvm-rhev security, bug fix, and enhancement update 2017-08-01 20:04:36 UTC

Description Ping Li 2016-09-23 06:19:48 UTC
Description of problem:
When create a qcow2 image with a large size(like 30720T), Message "qemu-img: test_large.qcow2: Active L1 table too large" will be provided. But when resize a qcow2 image with the size, the operation can be finished without any error. In either case, the image is failed to check info through qemu-img.

Version-Release number of selected component (if applicable):
# rpm -qa | grep qemu-kvm
qemu-kvm-rhev-2.6.0-25.el7.x86_64
# uname -r
3.10.0-510.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Create a qcow2 image with large size
    # qemu-img create -f qcow2 test_large.qcow2 30720T
Formatting 'test_large.qcow2', fmt=qcow2 size=33776997205278720 encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16
qemu-img: test_large.qcow2: Active L1 table too large
    # qemu-img info test_large.qcow2 
qemu-img: Could not open 'test_large.qcow2': Active L1 table too large

2. Resize a qcow2 image with large size
    # qemu-img create -f qcow2 test.qcow2 1G
Formatting 'test.qcow2', fmt=qcow2 size=1073741824 encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16
    # qemu-img info test.qcow2 
image: test.qcow2
file format: qcow2
virtual size: 1.0G (1073741824 bytes)
disk size: 196K
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false
    # qemu-img resize test.qcow2 +30720T
Image resized.
    # qemu-img info test.qcow2 
qemu-img: Could not open 'test.qcow2': Active L1 table too large

Actual results:
Operation resize can be finished successfully.

Expected results:
Operation resize should be failed as operation create.

Additional info:
There is a related upstream bug:
https://bugs.launchpad.net/qemu/+bug/1592590

Comment 4 Ping Li 2017-01-13 09:07:09 UTC
Hi Max,

Create image command failed when image size is 30720T. But the image can be created successfully. It should be no image created when command failed.


Host kernel and qemu version:
# uname -r
3.10.0-541.el7.x86_64
# /usr/libexec/qemu-kvm -version
qemu-kvm-rhev-2.8.0-1.el7

Test steps:
# qemu-img create -f qcow2 test_large.qcow2 30720T
Formatting 'test_large.qcow2', fmt=qcow2 size=33776997205278720 encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16
qemu-img: test_large.qcow2: The image size is too large for file format 'qcow2' (try using a larger cluster size)
# echo $?    ------> command failed
1
# qemu-img info test_large.qcow2image: test_large.qcow2    ------> but image 
file format: qcow2                                                 created
virtual size: 0 (0 bytes)
disk size: 192K
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

# qemu-img create -f qcow2 test.qcow2 1G
Formatting 'test.qcow2', fmt=qcow2 size=1073741824 encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16
# qemu-img info test.qcow2
image: test.qcow2
file format: qcow2
virtual size: 1.0G (1073741824 bytes)
disk size: 196K
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false
# qemu-img resize test.qcow2 +30720T
qemu-img: Error resizing image: File too large
# echo $?
1
# qemu-img info test.qcow2 
image: test.qcow2
file format: qcow2
virtual size: 1.0G (1073741824 bytes)
disk size: 196K
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

Comment 5 Max Reitz 2017-01-13 18:20:04 UTC
Hi pingl,

The image file is created, but as you can see its virtual size is 0. It would not be really trivial to not create the image file if the size specified is too large.

Besides, there are other things that can go wrong during image creation that result in a pretty much unusable image file lying around. It's always possible for "qemu-img create" to have created the file even on failure. It is not intended to be an atomic operation.

Therefore, I consider this working as intended.

Also, I think it's fine that users who get into this corner case of trying to create absurdly large image files have to deal with a bit of inconvenience.

Max

Comment 7 Ping Li 2017-01-17 12:28:33 UTC
According to comment 4 and 5, set the bug as verified.

Comment 9 errata-xmlrpc 2017-08-01 23:37:14 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2392

Comment 10 errata-xmlrpc 2017-08-02 01:14:54 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2392

Comment 11 errata-xmlrpc 2017-08-02 02:06:52 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2392

Comment 12 errata-xmlrpc 2017-08-02 02:47:39 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2392

Comment 13 errata-xmlrpc 2017-08-02 03:12:20 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2392

Comment 14 errata-xmlrpc 2017-08-02 03:32:30 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2392


Note You need to log in before you can comment on or make changes to this bug.