On Fri, Mar 14, 2025 at 11:12:09 -0000, Michael Niehren wrote: > Hi, > > currently i use on all VM's qcow2-Images with zlib compression. If i do an Backup, the Backup-Image will > be compressed with zstd Level 3 to shrink the image for transfering it over not so fast internet connections. Libvirt doesn't override the defaults that qemu selects when creating images. > So, why not directly using zstd compression on the images. Are there any reason's not to do that ? One reason is compatibility. Libvirt wants the images to stay compatible thus we must not switch to anything new by default. > As i always use virt-manager for administration, i patched qemu (V9.2.2) to create on default zstd compressed images > (only 1 change in line 3525). So newly created images do have compression type zstd, which work's (qemi-img info). > I see one unusual thing. If i do an qemi-img convert with compression_type=zstd the size of the converted image > is much smaller than the original file while "qemu-img info" shows on both as compression type zstd. Do they use > different compression levels, maybe ? Setting the compression algorithm on the qcow2 image doesn't mean that qemu will write compressed data into it. This is controlled either by the use of 'filter-compress' blockdev layer or e.g. the compress parameter of the backup job. > If i now do an virsh backup-begin <domain>, the backup-Image does also has a bigger size than the original, while > showing zstd as compression type (qemu-img info). If i convert it with the similar command as above, both converted images has > nearly the same size. Even if i copy the smaller converted image to the original and boot the vm from the smaller > image, the backup-image (after backup-begin) is bigger. As noted above the fact that any compression algorithm is enabled doesn't mean that compressed data will be written. I don't see us ever wanting to enable compression for the main disk image for performance reasons. Said that makes likely sense to allow enabling compression for the backup job as an option and should be relatively straightforward to do. The more intricate bit will be wiring up XML for selecting non-default compression format for the image created by libvirt (otherwise '--reuse-external' and manual creation would be needed.
