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.
Bug 1417306 - QEMU image file locking (libguestfs)
Summary: QEMU image file locking (libguestfs)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libguestfs
Version: 7.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: 7.4
Assignee: Richard W.M. Jones
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 1378241 1378242 1432523 1472272
Blocks: 1415250 1415252 1469590
TreeView+ depends on / blocked
 
Reported: 2017-01-27 22:02 UTC by Ademar Reis
Modified: 2018-04-10 09:15 UTC (History)
24 users (show)

Fixed In Version: libguestfs-1.36.6-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Qcow2 image file locking When opening a .qcow2 image file in read-write mode using libguestfs utilities, the QEMU emulator now locks the image, which prevents other processes from modifying the image at the same time and possibly corrupting the image data.
Clone Of: 1378241
Environment:
Last Closed: 2018-04-10 09:15:08 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:0677 0 normal SHIPPED_LIVE libguestfs new packages, bug fix and enhancement update 2018-04-10 13:13:49 UTC

Description Ademar Reis 2017-01-27 22:02:07 UTC 
+++ This bug was initially created as a clone of Bug #1378241 +++

QEMU image locking, which should prevent multiple runs of QEMU or qemu-img when a VM is running.

Upstream series (v7): https://lists.gnu.org/archive/html/qemu-devel/2016-08/msg01306.html
Comment 2 juzhang 2017-02-03 01:34:11 UTC 
Hi Lei,

Could you review this bz and mark qa_ack+?

Best Regards,
Junyi
Comment 5 Richard W.M. Jones 2017-09-05 15:33:21 UTC 
https://www.redhat.com/archives/libguestfs/2017-September/msg00014.html
Comment 6 Richard W.M. Jones 2017-09-14 17:04:55 UTC 
This is upstream in quite a long set of commits:

410593e48b1b9c471a0fffcc7bf140d7424acb31
0eb1380ddc9621d678661e831fad502a2830891f
ea94f39e465faf9a83ba761e8a24a037b9ea9f86
a22eecbdb1057531195faace657510da4a569829
bf7d627305418284682cc6020189215a5015dbad
3d2b84231fca14b7e2beeeeab0e852f44dba0c21
9fe592808ccfd9ed184b88ca9c6cad2e1798dee3
Comment 7 Richard W.M. Jones 2017-09-14 17:05:35 UTC 
I'm going to backport these to 1.36 so hopefully no extra
work will be required for RHEL 7.5.
Comment 9 YongkuiGuo 2017-10-13 07:48:40 UTC 
Hi rjones,

I tried to verify this bug with packages of libguestfs-1.36.7-1.el7.x86_64 and qemu-xxx-rhev-2.10.0-1.el7.x86_64. After running 'guestfish -v -x -a RHEL-Server-7.3-64-hvm.raw' command, i cannot see 'locking=off' info which you added in patch according to comment 5. How should I verify this bug? thx
Comment 10 Richard W.M. Jones 2017-10-13 07:52:08 UTC 
You should see it if you set the backend to direct and use --ro:

LIBGUESTFS_BACKEND=direct guestfish -v -x --ro -a rhel.raw -i

However for normal operations through libvirt, we are still waiting
on libvirt changes so that won't work.
Comment 11 YongkuiGuo 2017-10-13 09:28:27 UTC 
(In reply to Richard W.M. Jones from comment #10)
> You should see it if you set the backend to direct and use --ro:
> 
> LIBGUESTFS_BACKEND=direct guestfish -v -x --ro -a rhel.raw -i
> 
> However for normal operations through libvirt, we are still waiting
> on libvirt changes so that won't work.

I set the backend to direct but omitted the '--ro' option. Now the guestfish result contains 'backing.file.locking=off' info. 

But I am a bit confused. I downgraded the libguestfs version to 1.36.3. The version of qemu is still 2.10.0. Again run 'LIBGUESTFS_BACKEND=direct guestfish -v -x --ro -a RHEL-Server-7.3-64-hvm.raw -i', then continued to execute '!qemu-img info /home/RHEL-Server-7.3-64-hvm.raw' successfully in guestfish shell. Is it normal that the qemu-img command still can read info from raw file? I saw a line 'Since qemu 2.10, qemu locks all drives even when they are opened readonly.' in your patch.
Comment 12 Richard W.M. Jones 2017-10-13 09:35:48 UTC 
(In reply to YongkuiGuo from comment #11)
> But I am a bit confused. I downgraded the libguestfs version to 1.36.3. The
> version of qemu is still 2.10.0. Again run 'LIBGUESTFS_BACKEND=direct
> guestfish -v -x --ro -a RHEL-Server-7.3-64-hvm.raw -i', then continued to
> execute '!qemu-img info /home/RHEL-Server-7.3-64-hvm.raw' successfully in
> guestfish shell. Is it normal that the qemu-img command still can read info
> from raw file? I saw a line 'Since qemu 2.10, qemu locks all drives even
> when they are opened readonly.' in your patch.

It looks as if ‘qemu-img info’ does not acquire a lock if the
format is raw.  This makes sense because there's no reason to
acquire a lock simply to read the size of a raw file.

However what's a bit more surprising is that ‘qemu-img info’ also
does not acquire a lock if the format is qcow2.  I would have expected
that, so that could be a bug (in qemu-img).
Comment 13 Richard W.M. Jones 2017-10-13 09:45:10 UTC 
OK I talked to Fam about this, and in fact this is expected behaviour.

When using --ro, libguestfs creates an overlay on top of the image
(image is the backing file).  In this case it is expected that
qemu-img info will still be able to work on the backing file.
Comment 14 YongkuiGuo 2017-10-16 09:46:23 UTC 
Verified with packages:
libguestfs-1.36.7-1.el7.x86_64
qemu-kvm-rhev-2.10.0-1.el7.x86_64
qemu-img-rhev-2.10.0-1.el7.x86_64

Steps:

1. 
# LIBGUESTFS_BACKEND=direct guestfish -v -x --ro -a RHEL-Server-7.3-64-hvm.raw -i
--------------------------------------------------------------
...
[28259ms] /usr/libexec/qemu-kvm \
    -global virtio-blk-pci.scsi=off \
    -nodefconfig \
    -enable-fips \
    -nodefaults \
    -display none \
    -machine accel=kvm:tcg \
    -cpu host \
    -m 500 \
    -no-reboot \
    -rtc driftfix=slew \
    -no-hpet \
    -global kvm-pit.lost_tick_policy=discard \
    -kernel /var/tmp/.guestfs-0/appliance.d/kernel \
    -initrd /var/tmp/.guestfs-0/appliance.d/initrd \
    -object rng-random,filename=/dev/urandom,id=rng0 \
    -device virtio-rng-pci,rng=rng0 \
    -device virtio-scsi-pci,id=scsi \
    -drive file.file.filename=/tmp/libguestfsvtLE4Y/overlay1.qcow2,cache=unsafe,file.driver=qcow2,file.backing.file.locking=off,id=hd0,if=none \
    -device scsi-hd,drive=hd0 \
    -drive file=/var/tmp/.guestfs-0/appliance.d/root,snapshot=on,id=appliance,cache=unsafe,if=none,format=raw \
...

--------------------------------------------------------------
The output contains 'locking=off'. So verified this bug.
Comment 20 errata-xmlrpc 2018-04-10 09:15:08 UTC 
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/RHBA-2018:0677
Note You need to log in before you can comment on or make changes to this bug.