Re: General use of zstd instead of zlib compression
On Mon, Mar 17, 2025 at 09:31:55 +, Daniel P. Berrangé wrote: > On Fri, Mar 14, 2025 at 03:34:46PM +0100, Peter Krempa wrote: > > On Fri, Mar 14, 2025 at 14:18:03 -, Michael Niehren wrote: > > > one more ... > > > > > > what would happen, if i create the qcow2 image with zstd compression > > > enabled and > > > use the '--reuse-external' flag ? > > > Would qemu write compressed data in it or not ? > > > > It would not be compressed, as I've explained earlier (On technical > > lists it's preferred if context from what you're replying to is not > > trimmed so that it can be reffred back to) actual compression of blocks > > needs to be requested explicitly. The qcow2 header setting merely states > > which algorithm should be used if blocks are compressed. > > Also, AFAIK, qemu will not write compressed data during "normal" usage > by a running VM. The compression only gets applied during full image So there is the 'compress' filter in qemu although based on the only bit of "documentation" it has (commit message) QCOW2 supports compressed writes only for previously unallocated clusters so in fact it is used only for backups IIUC.
Re: General use of zstd instead of zlib compression
So to archive my goal to have an zstd compressed backup image, i can currently not use the new approach with backup-begin ? Instead i have to use the old approach with the overlay file and use qemu-img convert compression_type=zstd ... for doing the backup and if finished blockcommit the overlay file. am i right ?
Re: General use of zstd instead of zlib compression
On Fri, Mar 14, 2025 at 03:34:46PM +0100, Peter Krempa wrote: > On Fri, Mar 14, 2025 at 14:18:03 -, Michael Niehren wrote: > > one more ... > > > > what would happen, if i create the qcow2 image with zstd compression > > enabled and > > use the '--reuse-external' flag ? > > Would qemu write compressed data in it or not ? > > It would not be compressed, as I've explained earlier (On technical > lists it's preferred if context from what you're replying to is not > trimmed so that it can be reffred back to) actual compression of blocks > needs to be requested explicitly. The qcow2 header setting merely states > which algorithm should be used if blocks are compressed. Also, AFAIK, qemu will not write compressed data during "normal" usage by a running VM. The compression only gets applied during full image conversion processes. iow, 'qemu-img convert' can be used to create a compressed image, from a non-compressed image. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
system cache dropped
Hi, I have a setup with multiple virtual machines (VMs), each with a saved state. All VMs share the same parent, which is located on a shared drive. Whenever I restore any VM using virsh restore, the parent is dropped from the system cache, causing all data to be downloaded from the shared drive again. This results in unnecessary network traffic, even though the parent changes very rarely. However, if I create a child from the parent and call virsh create to create a new VM, the parent is never dropped from the system cache. Is this expected behavior? Should the parent be retained in the system cache during a virsh restore operation? Are there any configurations or settings that can prevent the parent from being dropped from the cache? thanks
