Description of problem: The target luks images by 'qemu-img convert' from raw/qcow2 images does not thin_provison, it will consume more time. Version-Release number of selected component (if applicable): qemu-kvm-3.1.0-22.module+el8.0.1+3032+a09688b9 kernel-4.18.0-80.el8 Local host(xfs): # df -T base.qcow2 Filesystem Type 1K-blocks Used Available Use% Mounted on /dev/mapper/rhel_lenovo--sr630--02-home xfs 514894144 21243480 493650664 5% /home How reproducible: 100% Steps to Reproduce: For source images with qcow2: 1. Create a source image # qemu-img create -f qcow2 base.qcow2 5G Formatting 'base.qcow2', fmt=qcow2 size=5368709120 cluster_size=65536 lazy_refcounts=off refcount_bits=16 # qemu-io -c 'write -P 1 0 1G' base.qcow2 wrote 1073741824/1073741824 bytes at offset 0 1 GiB, 1 ops; 0:00:06.10 (167.722 MiB/sec and 0.1638 ops/sec) # qemu-img info base.qcow2 image: base.qcow2 file format: qcow2 virtual size: 5.0G (5368709120 bytes) disk size: 1.0G cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false 2. Convert the image to luks # qemu-img convert -f qcow2 -O luks --object secret,id=sec0,data=convert -o key-secret=sec0 base.qcow2 tgt.luks -p (100.00/100%) 3. Check the info of the target image # qemu-img info tgt.luks image: tgt.luks file format: luks virtual size: 5.0G (5368709120 bytes) disk size: 5.0G ------------------ fully allocated!!! encrypted: yes Format specific information: ivgen alg: plain64 hash alg: sha256 cipher alg: aes-256 uuid: bba81fbd-c86c-4836-91cc-be18cec7a242 cipher mode: xts slots: [0]: active: true iters: 1131882 key offset: 4096 stripes: 4000 [1]: active: false key offset: 262144 [2]: active: false key offset: 520192 [3]: active: false key offset: 778240 [4]: active: false key offset: 1036288 [5]: active: false key offset: 1294336 [6]: active: false key offset: 1552384 [7]: active: false key offset: 1810432 payload offset: 2068480 master key iters: 282482 For source images with raw format: 1. Create a source image # qemu-img create -f raw base.img 5G Formatting 'base.img', fmt=raw size=5368709120 # qemu-io -c 'write -P 1 0 1g' base.img -f raw wrote 1073741824/1073741824 bytes at offset 0 1 GiB, 1 ops; 0:00:05.90 (173.438 MiB/sec and 0.1694 ops/sec) # qemu-img info base.img image: base.img file format: raw virtual size: 5.0G (5368709120 bytes) disk size: 1.0G 2. Convert to luks image # qemu-img convert -f raw -O luks --object secret,id=sec0,data=convert -o key-secret=sec0 base.img tgt_from_raw.luks -p (100.00/100%) 3. Check info of the target image # qemu-img info tgt_from_raw.luks image: tgt_from_raw.luks file format: luks virtual size: 5.0G (5368709120 bytes) disk size: 5.0G --------------------- Fully allocated!!! encrypted: yes Format specific information: ivgen alg: plain64 hash alg: sha256 cipher alg: aes-256 uuid: 618fc503-0fcd-45a0-9d2c-ee7dace4bc4f cipher mode: xts slots: [0]: active: true iters: 1143734 key offset: 4096 stripes: 4000 [1]: active: false key offset: 262144 [2]: active: false key offset: 520192 [3]: active: false key offset: 778240 [4]: active: false key offset: 1036288 [5]: active: false key offset: 1294336 [6]: active: false key offset: 1552384 [7]: active: false key offset: 1810432 payload offset: 2068480 master key iters: 285861 Actual results: As above. Expected results: The target luks images should be thin_provisioned. Additional info:
I am afraid that this is duplicate of 1535894 And it will be WONTFIX for the same reason. *** This bug has been marked as a duplicate of bug 1535894 ***