Re: Compact backing chain (sparsify + compress)

[Markus Armbruster <armbru@redhat.com>]

Adding cc:s.

Christopher Pereira <kripper@imatronix.cl> writes:

> Hi,
>
> I would like to revisit this old thread from 2016 with a special use case that I believe should be a standard `virsh` command:
> https://lists.gnu.org/archive/html/qemu-devel/2016-12/msg03571.html
>
> **Summary:**
>
> Given this QEMU backing chain:
> `base <- snap1 <- snap2 <- snap3 (active)`
>
> We want to merge `base <- snap1 <- snap2` into a new snapshot `collapsed-base` that is:
> 1. Sparsified (`virt-sparsify`)
> 2. Compressed
>
> The resulting backing chain would be:
> `collapsed-base <- snap3 (active)`
>
> **Motivation:**
>
> - We perform daily backup snapshots and never modify existing files (too dangerous). We only rebase.
> - We collapse older chains into a new `collapsed-base` snapshot to limit chain size and avoid performance degradation.
>
> We have been doing this successfully for over 10 years using:
>
> - `qemu-img convert`
> - `virt-sparsify`
> - `virsh save`
> - `qemu-img rebase`
> - `virsh resume`
>
> **Problems:**
>
> - There is a small downtime due to `virsh save`/`resume`.
> - In recent QEMU versions, `virsh` adds a `backingStore` tag to the XML even when using the `--no-metadata` option. This causes inconsistencies after `qemu-img rebase`.
>
> We didn’t use QMP because it didn’t support sparsify + compression in the past.
>
> **Questions:**
>
> - Is there now a better way to achieve this?
> - Could this feature be implemented or supported directly in `virsh`?
>
> In my opinion, this would be the ideal backup solution: we could travel in time, sync immutable snapshots to a remote backup server, and maintain performance.