Eric, care to take a look and update?

(In reply to Klaus Heinrich Kiwi from comment #3)
> Eric, care to take a look and update?

Eric,

 any updates? How likely is it for us to have this in 9.0-GA?

This should be doable for 9.0-GA. filter-compress has been in upstream qemu since 5.0.  Either the compress filter is already on the list of active block drivers, or it should be a simple patch to the downstream patch to add it.  But right now I need to figure out which downstream patch implements our current whitelist to definitively answer that.

The configure line in the current .distro/qemu-kvm.spec.template file for rhel 9 mentions only:
%global block_drivers_rw_list qcow2,raw,file,host_device,nbd,iscsi,rbd,blkdebug,luks,null-co,nvme,copy-on-read,throttle

which does not mention compress by name. But it also does not reject compress.  A quick build of the spec file and testing the just-built qemu-nbd with driver=compress in the command line worked for me, so it does appear to be built in.  Otherwise, it's a one-line patch to explicitly add it to our rw_list.

Hi Eric,

Could you please help to check whether the verifying steps are okay/enought? Thanks.


Tested with:
qemu-kvm-6.1.0-7.el9
kernel-5.14.0-15.el9.x86_64


Steps:
1. Create a compressed qcow2 image via qemu-img.
# qemu-img create -f qcow2 new.qcow2 2G
# qemu-io -c 'write -P 1 0 1G' new.qcow2
# qemu-img convert -f qcow2 -O qcow2 -c new.qcow2 new.compressed.qcow2 -p

2. Export the compressed image via qemu-nbd
# qemu-nbd --image-opts driver=compress,file.driver=qcow2,file.file.driver=file,file.file.filename=new.compressed.qcow2 -t &

3. Check the image info
# qemu-img info nbd://localhost:10809
image: nbd://localhost:10809
file format: raw
virtual size: 2 GiB (2147483648 bytes)
disk size: unavailable



BTW, the steps are also works in qemu-kvm-6.1.0-1.el9.
# qemu-img --version
qemu-img version 6.1.0 (qemu-kvm-6.1.0-1.el9)
Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers

# qemu-nbd --image-opts driver=compress,file.driver=qcow2,file.file.driver=file,file.file.filename=new.compressed.qcow2 -t &
[1] 162472
# qemu-img info nbd://localhost:10809
image: nbd://localhost:10809
file format: raw
virtual size: 2 GiB (2147483648 bytes)
disk size: unavailable

(In reply to Tingting Mao from comment #11)
> Hi Eric,
> 
> Could you please help to check whether the verifying steps are okay/enought?
> Thanks.
> 
> 
> Tested with:
> qemu-kvm-6.1.0-7.el9
> kernel-5.14.0-15.el9.x86_64
> 
> 
> Steps:
> 1. Create a compressed qcow2 image via qemu-img.
> # qemu-img create -f qcow2 new.qcow2 2G
> # qemu-io -c 'write -P 1 0 1G' new.qcow2
> # qemu-img convert -f qcow2 -O qcow2 -c new.qcow2 new.compressed.qcow2 -p
> 
> 2. Export the compressed image via qemu-nbd
> # qemu-nbd --image-opts
> driver=compress,file.driver=qcow2,file.file.driver=file,file.file.
> filename=new.compressed.qcow2 -t &
> 
> 3. Check the image info
> # qemu-img info nbd://localhost:10809
> image: nbd://localhost:10809
> file format: raw
> virtual size: 2 GiB (2147483648 bytes)
> disk size: unavailable

The compress driver only makes a difference on writes.  We can read a compressed qcow2 image even without the compress driver in the mix, so you merely proved that the driver loaded, but not that it made a difference.  What you really want to test (to match what v2v actually needs to be available) is that you can pre-create an empty qcow2 image, then do a one-pass write into that image through the compress driver, and that the resulting qcow2 file is compressed yet equivalent contents to the original.  This is what I tested:

1. Create an non-empty qcow2 source image, and an empty destination
# qemu-img create -f qcow2 src.qcow2 2G
# qemu-io -f qcow2 -c 'write -P 1 0 1G' src.qcow2
# qemu-img create -f qcow2 dst.qcow2 2G

2. Export the destination wrapped by the compress driver, so that writes get compressed
# qemu-nbd --image-opts driver=compress,file.driver=qcow2,file.file.driver=file,file.file.filename=dst.qcow2 -t &

3. Copy into the destination, then end qemu-nbd
# qemu-img convert -f qcow2 -O raw -n --target-is-zero src.qcow2 nbd://localhost:10809
# kill $!

4. Check that the resulting image reads identically but is indeed compressed
# ls -l src.qcow2 dst.qcow2 
-rw-r--r--. 1 eblake eblake    1687607 Nov 22 08:47 dst.qcow2
-rw-r--r--. 1 eblake eblake 1074135040 Nov 22 08:44 src.qcow2
# qemu-img compare -f qcow2 -F qcow2 src.qcow2 dst.qcow2
Images are identical.

> 
> 
> 
> BTW, the steps are also works in qemu-kvm-6.1.0-1.el9.

Yes, by luck.  In that build, our code base was not explicitly mentioning whether to include or exclude the compress driver, but it happened to be enabled (that may or may not be an upstream bug that when we have an explicit accept list, drivers that were not explicitly mentioned still end up being available rather than on the exclude list - but addressing that is not the goal of this bug).  The change in this patch is that the compress driver is now explicit, rather than relying on luck for whatever the code base chooses as a default.  Adding the test ensures that we avoid future regressions for v2v's needs, even if we can't prove a change in behavior of luckily-on vs. explicitly-on.

You could _also_ test that:
$ qemu-img --help | grep 'Supported formats'
includes the 'compress' driver (it must be present if this patch is working).  I don't know if there is a way to make qemu-kvm cough up its list of enabled drivers, and that's somewhat unfortunate since the list of supported drivers may differ between qemu-img and qemu-kvm (v2v only cares that tools like qemu-img and qemu-nbd support the format; whether qemu-kvm must also support compress is a different question).

Thanks for Eric's info. And tried again.


Tested with:
qemu-kvm-6.1.0-7.el9
kernel-5.14.0-15.el9.x86_64


Steps:
1. Create an non-empty qcow2 source image, and an empty destination
# qemu-img create -f qcow2 src.qcow2 2G
# qemu-io -f qcow2 -c 'write -P 1 0 1G' src.qcow2
# qemu-img create -f qcow2 dst.qcow2 2G

2. Export the destination wrapped by the compress driver, so that writes get compressed
# qemu-nbd --image-opts driver=compress,file.driver=qcow2,file.file.driver=file,file.file.filename=dst.qcow2 -t &

3. Copy into the destination, then end qemu-nbd
# qemu-img convert -f qcow2 -O raw -n --target-is-zero src.qcow2 nbd://localhost:10809
# kill $!

4. Check that the resulting image reads identically but is indeed compressed
# ls -la src.qcow2 dst.qcow2 
-rw-r--r-- 1 root root    1687607 Nov 22 20:59 dst.qcow2
-rw-r--r-- 1 root root 1074135040 Nov 22 20:58 src.qcow2

5. Compare the source and target images, they are identical.
# qemu-img compare -f qcow2 -F qcow2 src.qcow2 dst.qcow2 
Images are identical.

6. Check the help doc for supported formats of qemu-img
# qemu-img --help| grep -i 'supported formats'
  '-h' with or without a command shows this help and lists the supported formats
Supported formats: blkdebug blklogwrites blkverify compress copy-on-read file ftp ftps host_cdrom host_device http https luks nbd null-aio null-co nvme preallocate qcow2 quorum raw rbd ssh throttle vdi vhdx vmdk vpc
                                                   ^^^^^^^^ 


Also, all the steps are work in qemu-kvm-6.1.0-1.el9 including the checked info of qemu-img:
# qemu-img --version
qemu-img version 6.1.0 (qemu-kvm-6.1.0-1.el9)
Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers

# qemu-img --help | grep -i 'supported formats'
  '-h' with or without a command shows this help and lists the supported formats
Supported formats: blkdebug blklogwrites blkverify compress copy-on-read file ftp ftps host_cdrom host_device http https luks nbd null-aio null-co nvme preallocate qcow2 quorum raw rbd ssh throttle vhdx vmdk vpc
                                                    ^^^^^^^

QE bot(pre verify): Set 'Verified:Tested,SanityOnly' as gating/tier1 test pass.

According to Comment 13, set this bug as verified.

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 (new packages: qemu-kvm), 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-2022:2307