1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
|
Failed to get shared "write" lock with 'qemu-img info'
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
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.
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
On 10/06/2017 09:09 AM, Jan Heidbrink wrote:
> 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?
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
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
On 10/6/17 10:30 AM, Daniel Berrange wrote:
> 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
>
The QEMU project is currently considering to move its bug tracking to
another system. For this we need to know which bugs are still valid
and which could be closed already. Thus we are setting older bugs to
"Incomplete" now.
If you still think this bug report here is valid, then please switch
the state back to "New" within the next 60 days, otherwise this report
will be marked as "Expired". Or please mark it as "Fix Released" if
the problem has been solved with a newer version of QEMU already.
Thank you and sorry for the inconvenience.
Hi,
What exactly is the problem now? As Eric explained in comment 3, "qemu-img info -U" is what needs to be used here. Daniel raised the problem of --force-share/-U being undocumented, but that’s no longer the case as of commit a7e326df1c116e99e, which was first included in the 2.12.0 release.
Max
Ah ok, I think this bug can be closed then.
I have the same problem
|