Bug 1208575

Summary: QMP lacks counterpart to 'qemu-img commit' that empties top image
Product: Red Hat Enterprise Linux 7 Reporter: Eric Blake <eblake>
Component: qemu-kvmAssignee: Jeff Cody <jcody>
Status: CLOSED WONTFIX QA Contact: jingzhao <jinzhao>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.2CC: chayang, hhuang, huding, juzhang, michen, rbalakri, virt-maint, xfu
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-10-01 03:11:50 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Eric Blake 2015-04-02 14:47:13 UTC
Description of problem:
Given a chain 'A <- B', the command 'qemu-img commit B' empties out the contents of B, as a way of changing the point-in-time from which B is tracking to the current moment.  We later added the ability to NOT empty B, by using 'qemu-img commit -d B', when the intent is to make A the new active image and discard B, as that is faster.  However, when QMP does an active commit, it does NOT empty B; it always behaves like the -d mode of qemu-img.  When you 'complete' the job, that makes sense (you are pivoting to a different active file, and discarding the top); but when you 'abort' the job, it might make sense to have the ability to empty the image to the point in time of the abort. That is, given these sectors (where - means read backing file),

A 1111   # snapshot sees 1111
B -22-   # guest sees 1221

qemu-img commit -d B and QMP commit/complete both leave us with:
A 1221   # guest sees 1221
B -22-   # snapshot sees 1221, but this is a time-bomb
and the next write of '33' gives us
A 1233   # guest sees 1233
B -22-   # would read 1223 which never existed, so time-bomb exploded and B is now invalid

qemu-img commit B leaves us with:
A 1221   # snapshot sees 1221
B ----   # guest sees 1221
and the next write of '33' gives us
A 1221   # snapshot sees 1221
B --33   # guest sees 1233

while QMP commit/abort leaves us with:
A 1221   # snapshot sees 1221
B -22-   # guest sees 1233
and the next write of '33' gives us
A 1221   # snapshot sees 1221
B -233   # guest sees 1233

Note that B has different contents, where the qemu-img contents make sense (show all changes since the point-in-time) but the QMP contents waste space (sector -2-- has not changed since the point-in-time, so dirty maps are incorrect and future operations spend more time than necessary)

Version-Release number of selected component (if applicable):
still present in upstream 2.3

How reproducible:
100%

Steps to Reproduce:
1.
2.
3.

Actual results:
QMP lacks a mode made available by qemu-img

Expected results:
It would be nice to have the option to abort an active commit and empty out the active file at the point in time of the abort, so that the dirty map of the active file now tracks only changes since the commit operation ended.

However, a word of caution: emptying out the active image when committing across more than one file at a time MUST be forbidden unless the backing chain is rewritten; I'll file a separate bug for the ability to rewrite backing chain during active commit, as it is related but might be implemented separately.


Additional info:
see also this thread: https://lists.gnu.org/archive/html/qemu-devel/2015-04/msg00276.html

Comment 2 Eric Blake 2015-04-02 15:21:18 UTC
see also bug 1208587