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.
+++ This bug was initially created as a clone of Bug #1671798 +++
Description of problem:
When discussing the use of 'auto-read-only' property for use with -blockdev so that libvirt is able to use block jobs I forgot that sVirt labelling of the backing chain images actually forbids the write permission. [1]
This means that the 'auto-read-only' property works as expected and opens the images as read-only in this case. This unfortunately means that when libvirt attempts a block-commit which needs to write into the backing chain we relabel the image to allow write, but qemu will not reopen it any more.
This means that we unfortunately still need a way to control reopening of the images of the backing chain:
1) automatically by block-commit doing the right thing
2) manually by providing an interface to achieve that
Libvirt is relabeling the files anyways so 2) is also acceptable.
[1] Unfortunately it's very unpleasant to run a development git image of libvirt under full enforcing selinux, thus I neglected todo when testing 'auto-read-only'. I'm sorry for that.
Comment 2Miroslav Rezanina
2019-04-25 03:52:26 UTC
-blockdev and sVirt not support RHEL7.7, so just do some regression test to make sure no breaks.
A regression test has been run on block_commit with backend:gluster and basic block commit test with kinds of backend(nfs, nbd, iscsi), bugs found as bellow:
New bugs:
Bug 1713647 - Block format 'nbd' does not support reopening files when do block commit
Bug 1713650 - [upstream]Failed to do block commit to NBD device with BLOCK_JOB_ERROR, error: "Invalid argument"
Existed bugs:
Bug 1711643 - qemu aborts in blockCommit: qemu-kvm: block.c:3486: bdrv_replace_node: Assertion `!({ _Static_assert(!(sizeof(*&from->in_flight) > 8), "not expecting: " "sizeof(*&from->in_flight) > ATOMIC_REG_SIZE"); __atomic_load_n(&from->in_flight, 0); })' failed.
Bug 1614623 - qemu and guest hang when guest poweroff after live commit with data-plane
Bug 1667307 - qemu and guest hang when hotunplug a device with block commit running on it (data-plane enable)
Bug 1683937 - [data plane] Qemu core dump for 'virtio_scsi_ctx_check: Assertion `blk_get_aio_context(d->conf.blk) == s->ctx' failed' when create a snapshot with blockdev-create
Bug 1553234 - RFE: synchronous mirror to prevent a long-running block-job-complete (qemu)
RBD Sever is broken, will add the result later if have any bugs.
So set this bug's status to "Verified" and track the left issue by the new/existed bugs.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHSA-2019:2553