Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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