The qemu and libvirt live merge APIs allow the contents of multiple adjacent snapshots to be merged with a single operation. If engine knows that multiple snapshots are going to be deleted it should submit them all in a single 'merge' call so the merging can be done more efficiently by qemu. Take the example chain: A-B-C (A is the base and C is the active layer) This chain has two snapshots (preserved in volumes A and B). Today if we wanted to reduce this chain to a single volume we would use two merge calls: merge(base=A, top=B) and merge(base=A, top=C) (If we removed the oldest snapshot first) -or- merge(base=B, top=C) and merge(base=A, top=B) (if we removed the newest snapshot first) These two operations could be consolidated into a single merge(base=A, top=C) which would merge the data from B and C into A. All of the live merge flows need to be evaluated to determine how they will work when multiple volumes are being merged simultaneously.
Can you quantify the improvement? If substantial, why is it 'low' ?
(In reply to Yaniv Kaul from comment #1) > Can you quantify the improvement? If substantial, why is it 'low' ? The improvement is principally in user experience. In cases where a VM has a lot of snapshots that need to be removed it can be labor intensive to "babysit" the merges and submit one after another. I have not done tests to check the actual copy efficiency but we would be reducing a lot of round-trip calls back and forth between engine and vdsm, waiting for state transitions, etc. I am sure qemu would copy more efficiently as well. The severity is "low" because it currently works and this is not as important as block device watermark tracking during live merge.