Bug 1298605

Summary: [RFE] Live Merge: Merge adjacent snapshots concurrently
Product: [oVirt] vdsm Reporter: Adam Litke <alitke>
Component: RFEsAssignee: Ala Hino <ahino>
Status: CLOSED WONTFIX QA Contact: Raz Tamir <ratamir>
Severity: low Docs Contact:
Priority: low    
Version: 4.17.19CC: alitke, amureini, bugs, ylavi
Target Milestone: ---Keywords: FutureFeature, Performance
Target Release: ---Flags: sbonazzo: ovirt-4.2-
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-06-11 13:16:03 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Storage RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Adam Litke 2016-01-14 14:32:28 UTC 
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.
Comment 1 Yaniv Kaul 2016-01-17 11:02:12 UTC 
Can you quantify the improvement? If substantial, why is it 'low' ?
Comment 2 Adam Litke 2016-03-09 15:46:43 UTC 
(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.