Re: General use of zstd instead of zlib compression
On Fri, Mar 14, 2025 at 13:33:04 -0000, Michael Niehren wrote:
An implementation only in the backup job would be great, that would
fit my needs.
Maybe some more flags in the backupxml file would be useful. I used for compressing
on the zstd call
"--sparse --rsyncable -B128 "
as the files are later transfered with rsync. The compression level would also be useful
to set.
qcow2 doesn't seem to support any other configuration options for
compression:
##
# @BlockdevCreateOptionsQcow2:
#
# Driver specific image creation options for qcow2.
#
# @file: Node to create the image format on
#
# @data-file: Node to use as an external data file in which all guest
# data is stored so that only metadata remains in the qcow2 file
# (since: 4.0)
#
# @data-file-raw: True if the external data file must stay valid as a
# standalone (read-only) raw image without looking at qcow2
# metadata (default: false; since: 4.0)
#
# @extended-l2: True to make the image have extended L2 entries
# (default: false; since 5.2)
#
# @size: Size of the virtual disk in bytes
#
# @version: Compatibility level (default: v3)
#
# @backing-file: File name of the backing file if a backing file
# should be used
#
# @backing-fmt: Name of the block driver to use for the backing file
#
# @encrypt: Encryption options if the image should be encrypted
#
# @cluster-size: qcow2 cluster size in bytes (default: 65536)
#
# @preallocation: Preallocation mode for the new image (default: off;
# allowed values: off, falloc, full, metadata)
#
# @lazy-refcounts: True if refcounts may be updated lazily
# (default: off)
#
# @refcount-bits: Width of reference counts in bits (default: 16)
#
# @compression-type: The image cluster compression method
# (default: zlib, since 5.1)
#
# Since: 2.12
##
{ 'struct': 'BlockdevCreateOptionsQcow2',
'data': { 'file': 'BlockdevRef',
'*data-file': 'BlockdevRef',
'*data-file-raw': 'bool',
'*extended-l2': 'bool',
'size': 'size',
'*version': 'BlockdevQcow2Version',
'*backing-file': 'str',
'*backing-fmt': 'BlockdevDriver',
'*encrypt': 'QCryptoBlockCreateOptions',
'*cluster-size': 'size',
'*preallocation': 'PreallocMode',
'*lazy-refcounts': 'bool',
'*refcount-bits': 'int',
'*compression-type':'Qcow2CompressionType' } }
By the way, is the backup qcow2 file written from qemu or from libvirt, when calling
backup-begin ?
Normally libvirt creates an empty file, applies security labelling for
qemu to be able to access it.
Then qemu is instructed to open the backing file (blockdev-add), format
it with a qcow2 header (blockdev-create) and then start the backup job
(transaction + blockdev-backup).
In case '--reuse-external' flag is used, libvirt expects that the file
was pre-created by the user with proper metadata (most importantly
proper size + whatever configuration the user wants). Libvirt applies
security labels and then uses blockdev-add + (transaction +
blockdev-backup) to do the backup.
The actual backup is always done by qemu in push mode.
In pull mode the same as above happens for the 'scratch' temporary file
needed to do the backup. libvirt then instructs qemu to start a NBD
server where the user can pull the backup from.