Discussion:
[Qemu-devel] [Bug 1721788] [NEW] Failed to get shared "write" lock with 'qemu-img info'
Jan Heidbrink
2017-10-06 14:09:18 UTC
Permalink
Public bug reported:

When running 'qemu-img info test.qcow2' while test.qcow2 is currently
used by a Qemu process, I get the error

qemu-img: Could not open 'test.qcow2': Failed to get shared "write"
lock.


Why does displaying information about a disk image need a write lock for the file?

Steps to reproduce:

qemu-img create -f qcow2 test.qcow2 10M
qemu-system-x86_64 -nographic -drive file=test.qcow2
qemu-img info test.qcow2

The above was tested with Qemu version 2.10.0

** Affects: qemu
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1721788

Title:
Failed to get shared "write" lock with 'qemu-img info'

Status in QEMU:
New

Bug description:
When running 'qemu-img info test.qcow2' while test.qcow2 is currently
used by a Qemu process, I get the error

qemu-img: Could not open 'test.qcow2': Failed to get shared "write"
lock.


Why does displaying information about a disk image need a write lock for the file?

Steps to reproduce:

qemu-img create -f qcow2 test.qcow2 10M
qemu-system-x86_64 -nographic -drive file=test.qcow2
qemu-img info test.qcow2

The above was tested with Qemu version 2.10.0

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1721788/+subscriptions
Eric Blake
2017-10-06 14:28:48 UTC
Permalink
Post by Jan Heidbrink
When running 'qemu-img info test.qcow2' while test.qcow2 is currently
used by a Qemu process, I get the error
qemu-img: Could not open 'test.qcow2': Failed to get shared "write"
lock.
Why does displaying information about a disk image need a write lock for the file?
Because there is a risk (albeit rather slight) that what you read from
the disk is inconsistent due to being an intermediate state in-between
separate non-atomic write actions by the other process that has it open
for write.

If you are willing to ignore the risk, then use:

qemu-img info -U test.qcow2

which says that you are okay reading the image while it is shared with a
concurrent writer, even if the read fails spectacularly in the unlikely
case that it sees inconsistent information.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
Daniel Berrange
2017-10-06 14:28:37 UTC
Permalink
The QEMU process that has the disk image open may be doing I/O that
causes qcow2 metadata to be changed. Such changes could confuse the
'qemu-img' process it is was reading the metadata at the same time it
was being changed, causing bad data to be printed or worse. So requiring
a write lock is the 'safe' thing to do for reliability in the worst
case. You can override this by passing '--force-share' arg though.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1721788

Title:
Failed to get shared "write" lock with 'qemu-img info'

Status in QEMU:
New

Bug description:
When running 'qemu-img info test.qcow2' while test.qcow2 is currently
used by a Qemu process, I get the error

qemu-img: Could not open 'test.qcow2': Failed to get shared "write"
lock.


Why does displaying information about a disk image need a write lock for the file?

Steps to reproduce:

qemu-img create -f qcow2 test.qcow2 10M
qemu-system-x86_64 -nographic -drive file=test.qcow2
qemu-img info test.qcow2

The above was tested with Qemu version 2.10.0

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1721788/+subscriptions
Daniel Berrange
2017-10-06 14:30:14 UTC
Permalink
I've just noticed, however, that '--force-share' appears totally
undocumented in both CLI help output and the man page. So that's
certainly something that should be fixed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1721788

Title:
Failed to get shared "write" lock with 'qemu-img info'

Status in QEMU:
New

Bug description:
When running 'qemu-img info test.qcow2' while test.qcow2 is currently
used by a Qemu process, I get the error

qemu-img: Could not open 'test.qcow2': Failed to get shared "write"
lock.


Why does displaying information about a disk image need a write lock for the file?

Steps to reproduce:

qemu-img create -f qcow2 test.qcow2 10M
qemu-system-x86_64 -nographic -drive file=test.qcow2
qemu-img info test.qcow2

The above was tested with Qemu version 2.10.0

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1721788/+subscriptions
Liang Yan
2017-10-11 20:46:40 UTC
Permalink
This does  not only affect qemu-img only, it could not make libvirt
"<shareable>" work either when two vms were running with share disk
image.  Is there a workaround for this situation?

Best,
Liang
Post by Daniel Berrange
I've just noticed, however, that '--force-share' appears totally
undocumented in both CLI help output and the man page. So that's
certainly something that should be fixed
Loading...