Adding cc:s. Christopher Pereira <[email protected]> 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.
