+++ This bug was initially created as a clone of Bug #1171005 +++ Description of problem: qemu-img can not create qcow2 format image when backend is rbd server. Version-Release number of selected component (if applicable): qemu-kvm-1.5.3-83.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1.create qcow2 format image via qemu-img. # qemu-img create -f qcow2 rbd:qemu-kvm-pool/juli-test30.qcow2:mon_host=$IP 10M 2. 3. Actual results: After step1, qemu-img will give error message and can not create a correct qcow2 format image. # qemu-img create -f qcow2 rbd:qemu-kvm-pool/juli-test30.qcow2:mon_host=$IP 10M Formatting 'rbd:qemu-kvm-pool/juli-test30.qcow2:mon_host=$IP', fmt=qcow2 size=10485760 encryption=off cluster_size=65536 lazy_refcounts=off qemu-img: rbd:qemu-kvm-pool/juli-test30.qcow2:mon_host=$IP: Could not write qcow2 header: Input/output error Expected results: can create qcow2 image successfully. Additional info:
Version of components: qemu-kvm-rhev-2.1.2-14.el7.x86_64
Hi Kevin, As the flag rhel-7.4.0? is set, qe wonder to know whether the issue will be fixed in rhel 7.4? Then qe can add it to RHEL 7.4 test plan for disk format. Thanks.
No, this is still not a priority, so upstream didn't add the functionality yet.
I test the creation of qcow2 image on cephfs with preallocation mode, it succeeded. # qemu-img create -f qcow2 -o preallocation=full rbd:kvm-test/test1.qcow2:mon_host=10.73.199.64 1G Formatting 'rbd:kvm-test/test1.qcow2:mon_host=10.73.199.64', fmt=qcow2 size=1073741824 cluster_size=65536 preallocation=full lazy_refcounts=off refcount_bits=16 # qemu-img info rbd:kvm-test/test1.qcow2:mon_host=10.73.199.64 image: json:{"driver": "qcow2", "file": {"pool": "kvm-test", "image": "test1.qcow2", "driver": "rbd", "=keyvalue-pairs": "[\"mon_host\", \"10.73.199.64\"]"}} file format: qcow2 virtual size: 1.0G (1073741824 bytes) disk size: unavailable cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false
I test the creation of qcow2 image on cephfs with preallocation=full, it succeeded. But with "luks-inside-qcow2", it is failed. (1) preallocation=full, passed # qemu-img create -f qcow2 -o preallocation=full rbd:kvm-test/system.qcow2:mon_host=10.73.199.64 25G Formatting 'rbd:kvm-test/system.qcow2:mon_host=10.73.199.64', fmt=qcow2 size=26843545600 cluster_size=65536 preallocation=full lazy_refcounts=off refcount_bits=16 (2) luks-inside-qcow2, failed # qemu-img create --object secret,id=sec0,data=backing -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 rbd:kvm-test/system1.qcow2:mon_host=10.73.199.64 5G Formatting 'rbd:kvm-test/system1.qcow2:mon_host=10.73.199.64', fmt=qcow2 size=5368709120 encrypt.format=luks encrypt.key-secret=sec0 cluster_size=65536 lazy_refcounts=off refcount_bits=16 qemu-img: rbd:kvm-test/system1.qcow2:mon_host=10.73.199.64: Could not write qcow2 header: Invalid argument (3) preallocation=full + luks-inside-qcow2, failed # qemu-img create --object secret,id=sec0,data=backing -f qcow2 -o preallocation=full,encrypt.format=luks,encrypt.key-secret=sec0 rbd:kvm-test/system2.qcow2:mon_host=10.73.199.64 5G Formatting 'rbd:kvm-test/system2.qcow2:mon_host=10.73.199.64', fmt=qcow2 size=5368709120 encrypt.format=luks encrypt.key-secret=sec0 cluster_size=65536 preallocation=full lazy_refcounts=off refcount_bits=16 qemu-img: rbd:kvm-test/system2.qcow2:mon_host=10.73.199.64: Could not preallocate metadata: Invalid argument (4) preallocation=metadata + luks-inside-qcow2, failed # qemu-img create --object secret,id=sec0,data=backing -f qcow2 -o preallocation=metadata,encrypt.format=luks,encrypt.key-secret=sec0 rbd:kvm-test/system3.qcow2:mon_host=10.73.199.64 5G Formatting 'rbd:kvm-test/system3.qcow2:mon_host=10.73.199.64', fmt=qcow2 size=5368709120 encrypt.format=luks encrypt.key-secret=sec0 cluster_size=65536 preallocation=metadata lazy_refcounts=off refcount_bits=16 qemu-img: rbd:kvm-test/system3.qcow2:mon_host=10.73.199.64: Could not write qcow2 header: Invalid argument (5) preallocation=falloc + luks-inside-qcow2, failed # qemu-img create --object secret,id=sec0,data=backing -f qcow2 -o preallocation=falloc,encrypt.format=luks,encrypt.key-secret=sec0 rbd:kvm-test/system4.qcow2:mon_host=10.73.199.64 5G Formatting 'rbd:kvm-test/system4.qcow2:mon_host=10.73.199.64', fmt=qcow2 size=5368709120 encrypt.format=luks encrypt.key-secret=sec0 cluster_size=65536 preallocation=falloc lazy_refcounts=off refcount_bits=16 qemu-img: rbd:kvm-test/system4.qcow2:mon_host=10.73.199.64: Could not preallocate metadata: Invalid argument (6) preallocation=off + luks-inside-qcow2, failed # qemu-img create --object secret,id=sec0,data=backing -f qcow2 -o preallocation=off,encrypt.format=luks,encrypt.key-secret=sec0 rbd:kvm-test/system5.qcow2:mon_host=10.73.199.64 5G Formatting 'rbd:kvm-test/system5.qcow2:mon_host=10.73.199.64', fmt=qcow2 size=5368709120 encrypt.format=luks encrypt.key-secret=sec0 cluster_size=65536 preallocation=off lazy_refcounts=off refcount_bits=16 qemu-img: rbd:kvm-test/system5.qcow2:mon_host=10.73.199.64: Could not write qcow2 header: Invalid argument
*** Bug 1642304 has been marked as a duplicate of this bug. ***
I proposed a patch upstream with a workaround to fix this issue, but Jason Dillaman [1] pointed out a good observation: > What's the use-case for storing qcow2 images within a RBD image? RBD > images are already thinly provisioned, they support snapshots, they > can form a parent/child linked image hierarchy. Do you have in mind some use cases? One use case could be if you have a qcow2 image and you want to put it in the RBD pool without converting it, but I don't know if it is a practical use case. [1] https://lists.gnu.org/archive/html/qemu-devel/2019-04/msg01870.html
(In reply to Stefano Garzarella from comment #12) > I proposed a patch upstream with a workaround to fix this issue, but Jason > Dillaman [1] pointed out a good observation: > > What's the use-case for storing qcow2 images within a RBD image? RBD > > images are already thinly provisioned, they support snapshots, they > > can form a parent/child linked image hierarchy. > Honestly, I am not that clear about the snapshots within a RBD image. But after a simply test according to the official doc[1], I noticed that the snapshots created by 'rbd' command seems are internal snapshots, and work as Read-only? While for qcow2, we could use external snapshots. And we recommend users use external snapshots, which are more stable and maintained easier. > Do you have in mind some use cases? For qcow2, I think one of the most features is Copy-on-write, where the image only represents changes made to an underlying disk image. And optional compression and encryption. [1]http://docs.ceph.com/docs/giant/rbd/rbd-snapshot/
(In reply to Tingting Mao from comment #13) > (In reply to Stefano Garzarella from comment #12) > > I proposed a patch upstream with a workaround to fix this issue, but Jason > > Dillaman [1] pointed out a good observation: > > > What's the use-case for storing qcow2 images within a RBD image? RBD > > > images are already thinly provisioned, they support snapshots, they > > > can form a parent/child linked image hierarchy. > > > Honestly, I am not that clear about the snapshots within a RBD image. But > after a simply test according to the official doc[1], I noticed that the > snapshots created by 'rbd' command seems are internal snapshots, and work as > Read-only? Yes. > While for qcow2, we could use external snapshots. And we recommend users use > external snapshots, which are more stable and maintained easier. You can create a snapshot and clone an image to a new copy-on-write image for such a use-case. It would be way more efficient that having to copy the entire base qcow2 image to a new backing RBD image. > > Do you have in mind some use cases? > > For qcow2, I think one of the most features is Copy-on-write, where the > image only represents changes made to an underlying disk image. And optional > compression and encryption. Ceph supports at-rest compression and you can run LUKS on top of an image to support encryption. Is there an actual end-user use-case here that I am missing? > > [1]http://docs.ceph.com/docs/giant/rbd/rbd-snapshot/
The patch that allows the creation of qcow2 with rbd backend is upstream: commit d24f80234b39d2d5c0d91e63b5e4569d37b2399e Author: Stefano Garzarella <sgarzare> Date: Thu May 9 16:59:27 2019 +0200 block/rbd: increase dynamically the image size RBD APIs don't allow us to write more than the size set with rbd_create() or rbd_resize(). In order to support growing images (eg. qcow2), we resize the image before write operations that exceed the current size. Signed-off-by: Stefano Garzarella <sgarzare> Message-id: 20190509145927.293369-1-sgarzare Signed-off-by: Max Reitz <mreitz>
Verified this bug by regression test[1] - qcow2 with rbd. Besides below bugs, other functionality works well. So set this bug as verified. Thanks. New/existed bugs: Bug 1642332 - QEMU should refuse to boot a running image based on RBD Bug 1514373 - RFE: support preallocation=falloc/full/off when create raw image on cephfs Bug 1703923 - [upstream] Creating qcow2: external data file images over libiscsi fails Bug 1745885 - 'qemu-img create' an overlay over RBD should look up the directory containing the overlay to find it's backing file Bug 1746393 - There is some error msg in guest with qcow2 format over RBD after writing data in it [1]https://polarion.engineering.redhat.com/polarion/#/project/RedHatEnterpriseLinux7/workitems?query=project.id%3ARedHatEnterpriseLinux7%20AND%20type%3Atestcase%20AND%20linkedWorkItems%3ARHEL%5C-113419%20AND%20(NOT%20TEST_RECORDS%3A(%22RedHatEnterpriseLinux7%2FVirtkvmqe-x86-qcow2-rbd-manual-qemu-kvm-4-1-0-4-module-el8-1-0-RHEL-8-1%22%2C%40any))&sidebar=testrun&testrun=RedHatEnterpriseLinux7%2FVirtkvmqe-x86-qcow2-rbd-manual-qemu-kvm-4-1-0-4-module-el8-1-0-RHEL-8-1
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/RHBA-2019:3723