Description of problem: According to https://bugzilla.redhat.com/show_bug.cgi?id=1827630#c7, report this bug. tested with luks format, it works well. tested with luks-inside-qcow2, hit this issue. Version-Release number of selected component (if applicable): kernel-4.18.0-209.el8.x86_64 qemu-kvm-5.0.0-0.module+el8.3.0+6620+5d5e1420 How reproducible: 100% Steps to Reproduce: 1. # echo -n -e '\x3a\x3c\x3b\xff' > non_utf8_secret 2. # qemu-img create --object secret,id=sec0,file=non_utf8_secret -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 test.qcow2 1G 3. # ls test.qcow2 Actual results: after step 2: hit the error message, qemu-img: test.qcow2: Data from secret sec0 is not valid UTF-8. But the file test.qcow2 was created. # ls test.qcow2 test.qcow2 # qemu-img info test.qcow2 image: test.qcow2 file format: qcow2 virtual size: 1 GiB (1073741824 bytes) disk size: 196 KiB cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false Expected results: Any failures in image creation should revert back any changes. Additional info: This bug is for rhel8.3.0 fast train. Bug 1819743 is for rhel8.3.0 slow train.
NB: Removing IBM tracker bug 1776265 from blocks... If using qcow2 is a blocker for IBM, then we can clone this to a RHEL bug and add that to the tracker
Patch (which is mostly copy&pasta of the luks fix) send upstream: https://lists.nongnu.org/archive/html/qemu-devel/2020-07/msg05214.html
*sent
The patches to resolve this issue were merged upstream in qemu.git commit id 6094cbeb72117204f3302a4581415ee1dc33a879 Setting bz to POST w/ ITR=8.5.0 to indicate RHEL-AV will include this in the next qemu rebase rather than backporting the changes to 8.4.0 With the new ITM process included it's doubtful everything that needs to be done could be done by bug freeze and this is only a medium so it can wait
Tested with qemu-kvm-6.0.0-16.module+el8.5.0+10848+2dccc46d, not hit this issue. So set status to VERIFIED. Versions: kernel-4.18.0-305.1.el8.x86_64 qemu-kvm-6.0.0-16.module+el8.5.0+10848+2dccc46d 1. tested with luks format, it works well. # echo -n -e '\x3a\x3c\x3b\xff' > non_utf8_secret # qemu-img create -f luks --object secret,id=sec0,file=non_utf8_secret -o key-secret=sec0 test.raw 4M Formatting 'test.raw', fmt=luks size=4194304 key-secret=sec0 qemu-img: test.raw: Data from secret sec0 is not valid UTF-8 # ls test.raw ls: cannot access 'test.raw': No such file or directory 2. tested with luks-inside-qcow2, it works well. # qemu-img create --object secret,id=sec0,file=non_utf8_secret -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 test.qcow2 1G Formatting 'test.qcow2', fmt=qcow2 encrypt.format=luks encrypt.key-secret=sec0 cluster_size=65536 extended_l2=off compression_type=zlib size=1073741824 lazy_refcounts=off refcount_bits=16 qemu-img: test.qcow2: Data from secret sec0 is not valid UTF-8 # ls test.qcow2 ls: cannot access 'test.qcow2': No such file or directory
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 (virt:av bug fix and enhancement update), 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-2021:4684