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
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
|
boot: 0.881
other: 0.853
semantic: 0.843
KVM: 0.822
instruction: 0.821
mistranslation: 0.768
network: 0.718
[BUG, RFC] Base node is in RW after making external snapshot
Hi everyone,
When making an external snapshot, we end up in a situation when 2 block
graph nodes related to the same image file (format and storage nodes)
have different RO flags set on them.
E.g.
# ls -la /proc/PID/fd
lrwx------ 1 root qemu 64 Apr 24 20:14 12 -> /path/to/harddisk.hdd
# virsh qemu-monitor-command VM '{"execute": "query-named-block-nodes"}'
--pretty | egrep '"node-name"|"ro"'
"ro": false,
"node-name": "libvirt-1-format",
"ro": false,
"node-name": "libvirt-1-storage",
# virsh snapshot-create-as VM --name snap --disk-only
Domain snapshot snap created
# ls -la /proc/PID/fd
lr-x------ 1 root qemu 64 Apr 24 20:14 134 -> /path/to/harddisk.hdd
lrwx------ 1 root qemu 64 Apr 24 20:14 135 -> /path/to/harddisk.snap
# virsh qemu-monitor-command VM '{"execute": "query-named-block-nodes"}'
--pretty | egrep '"node-name"|"ro"'
"ro": false,
"node-name": "libvirt-2-format",
"ro": false,
"node-name": "libvirt-2-storage",
"ro": true,
"node-name": "libvirt-1-format",
"ro": false, <--------------
"node-name": "libvirt-1-storage",
File descriptor has been reopened in RO, but "libvirt-1-storage" node
still has RW permissions set.
I'm wondering it this a bug or this is intended? Looks like a bug to
me, although I see that some iotests (e.g. 273) expect 2 nodes related
to the same image file to have different RO flags.
bdrv_reopen_set_read_only()
bdrv_reopen()
bdrv_reopen_queue()
bdrv_reopen_queue_child()
bdrv_reopen_multiple()
bdrv_list_refresh_perms()
bdrv_topological_dfs()
bdrv_do_refresh_perms()
bdrv_reopen_commit()
In the stack above bdrv_reopen_set_read_only() is only being called for
the parent (libvirt-1-format) node. There're 2 lists: BDSs from
refresh_list are used by bdrv_drv_set_perm and this leads to actual
reopen with RO of the file descriptor. And then there's reopen queue
bs_queue -- BDSs from this queue get their parameters updated. While
refresh_list ends up having the whole subtree (including children, this
is done in bdrv_topological_dfs()) bs_queue only has the parent. And
that is because storage (child) node's (bs->inherits_from == NULL), so
bdrv_reopen_queue_child() never adds it to the queue. Could it be the
source of this bug?
Anyway, would greatly appreciate a clarification.
Andrey
On 4/24/24 21:00, Andrey Drobyshev wrote:
>
Hi everyone,
>
>
When making an external snapshot, we end up in a situation when 2 block
>
graph nodes related to the same image file (format and storage nodes)
>
have different RO flags set on them.
>
>
E.g.
>
>
# ls -la /proc/PID/fd
>
lrwx------ 1 root qemu 64 Apr 24 20:14 12 -> /path/to/harddisk.hdd
>
>
# virsh qemu-monitor-command VM '{"execute": "query-named-block-nodes"}'
>
--pretty | egrep '"node-name"|"ro"'
>
"ro": false,
>
"node-name": "libvirt-1-format",
>
"ro": false,
>
"node-name": "libvirt-1-storage",
>
>
# virsh snapshot-create-as VM --name snap --disk-only
>
Domain snapshot snap created
>
>
# ls -la /proc/PID/fd
>
lr-x------ 1 root qemu 64 Apr 24 20:14 134 -> /path/to/harddisk.hdd
>
lrwx------ 1 root qemu 64 Apr 24 20:14 135 -> /path/to/harddisk.snap
>
>
# virsh qemu-monitor-command VM '{"execute": "query-named-block-nodes"}'
>
--pretty | egrep '"node-name"|"ro"'
>
"ro": false,
>
"node-name": "libvirt-2-format",
>
"ro": false,
>
"node-name": "libvirt-2-storage",
>
"ro": true,
>
"node-name": "libvirt-1-format",
>
"ro": false, <--------------
>
"node-name": "libvirt-1-storage",
>
>
File descriptor has been reopened in RO, but "libvirt-1-storage" node
>
still has RW permissions set.
>
>
I'm wondering it this a bug or this is intended? Looks like a bug to
>
me, although I see that some iotests (e.g. 273) expect 2 nodes related
>
to the same image file to have different RO flags.
>
>
bdrv_reopen_set_read_only()
>
bdrv_reopen()
>
bdrv_reopen_queue()
>
bdrv_reopen_queue_child()
>
bdrv_reopen_multiple()
>
bdrv_list_refresh_perms()
>
bdrv_topological_dfs()
>
bdrv_do_refresh_perms()
>
bdrv_reopen_commit()
>
>
In the stack above bdrv_reopen_set_read_only() is only being called for
>
the parent (libvirt-1-format) node. There're 2 lists: BDSs from
>
refresh_list are used by bdrv_drv_set_perm and this leads to actual
>
reopen with RO of the file descriptor. And then there's reopen queue
>
bs_queue -- BDSs from this queue get their parameters updated. While
>
refresh_list ends up having the whole subtree (including children, this
>
is done in bdrv_topological_dfs()) bs_queue only has the parent. And
>
that is because storage (child) node's (bs->inherits_from == NULL), so
>
bdrv_reopen_queue_child() never adds it to the queue. Could it be the
>
source of this bug?
>
>
Anyway, would greatly appreciate a clarification.
>
>
Andrey
Friendly ping. Could somebody confirm that it is a bug indeed?
|