qemu/tests/qemu-iotests/group

316 lines
5.1 KiB
Plaintext
Raw Normal View History

#
# QA groups control file
# Defines test groups
#
# Some notes about the groups:
#
# - do not start group names with a digit
#
# - quick : Tests in this group should finish within some few seconds.
#
# - img : Tests in this group can be used to excercise the qemu-img tool.
#
# - auto : Tests in this group are used during "make check" and should be
# runnable in any case. That means they should run with every QEMU binary
# (also non-x86), with every QEMU configuration (i.e. must not fail if
# an optional feature is not compiled in - but reporting a "skip" is ok),
# work at least with the qcow2 file format, work with all kind of host
# filesystems and users (e.g. "nobody" or "root") and must not take too
# much memory and disk space (since CI pipelines tend to fail otherwise).
#
#
# test-group association ... one line per test
#
001 rw auto quick
002 rw auto quick
003 rw auto
004 rw auto quick
005 img auto quick
# 006 was removed, do not reuse
007 snapshot auto
008 rw auto quick
009 rw auto quick
010 rw auto quick
011 rw auto quick
012 auto quick
013 rw auto
014 rw
015 rw snapshot
# 016 was removed, do not reuse
017 rw backing auto quick
018 rw backing auto quick
019 rw backing auto quick
020 rw backing auto quick
021 io auto quick
022 rw snapshot auto
023 rw
024 rw backing auto quick
025 rw auto quick
026 rw blkdbg
027 rw auto quick
028 rw backing quick
029 rw auto quick
030 rw auto backing
031 rw auto quick
032 rw auto quick
033 rw auto quick
034 rw auto backing quick
035 rw auto quick
036 rw auto quick
037 rw auto backing quick
038 rw auto backing quick
039 rw auto quick
040 rw auto
041 rw auto backing
042 rw auto quick
043 rw auto backing
044 rw
045 rw quick
046 rw auto aio quick
047 rw auto quick
048 img auto quick
049 rw auto
050 rw auto backing quick
051 rw
052 rw auto backing quick
053 rw auto quick
054 rw auto quick
055 rw
056 rw backing
057 rw
058 rw quick
059 rw quick
060 rw auto quick
061 rw auto
062 rw auto quick
063 rw auto quick
064 rw quick
065 rw quick
066 rw auto quick
067 rw quick
068 rw quick
069 rw auto quick
070 rw quick
071 rw auto quick
072 rw auto quick
073 rw auto quick
074 rw auto quick
075 rw quick
076 io
077 rw quick
078 rw quick
079 rw auto
080 rw auto
081 rw quick
082 rw quick
083 rw
084 img quick
085 rw
086 rw auto quick
087 rw quick
088 rw quick
089 rw auto quick
090 rw auto quick
091 rw migration quick
092 rw quick
093 throttle
094 rw quick
095 rw quick
096 rw quick
097 rw auto backing
098 rw auto backing quick
099 rw auto quick
# 100 was removed, do not reuse
101 rw quick
102 rw quick
103 rw auto quick
104 rw auto
105 rw auto quick
106 rw quick
107 rw auto quick
108 rw auto quick
109 rw
110 rw auto backing quick
111 rw auto quick
112 rw
113 rw quick
114 rw auto quick
115 rw
116 rw quick
117 rw auto
118 rw
119 rw quick
120 rw auto quick
121 rw
122 rw
123 rw quick
124 rw backing
125 rw
126 rw auto backing
127 rw auto backing quick
128 rw quick
129 rw quick
130 rw quick
131 rw quick
132 rw quick
133 auto quick
134 rw auto quick
135 rw
136 rw
137 rw auto
138 rw auto quick
139 rw quick
140 rw auto quick
141 rw auto quick
142
143 auto quick
144 rw quick
145 quick
146 quick
147 img
148 rw quick
149 rw sudo
150 rw auto quick
151 rw
152 rw quick
153 rw quick
154 rw auto backing quick
155 rw
156 rw auto quick
157 quick
158 rw auto quick
159 rw auto quick
160 rw quick
block: Update BlockDriverState.inherits_from on bdrv_set_backing_hd() When a BlockDriverState's child is opened (be it a backing file, the protocol layer, or any other) inherits_from is set to point to the parent node. Children opened separately and then attached to a parent don't have this pointer set. bdrv_reopen_queue_child() uses this to determine whether a node's children must also be reopened inheriting the options from the parent or not. If inherits_from points to the parent then the child is reopened and its options can be changed, like in this example: $ qemu-img create -f qcow2 hd0.qcow2 1M $ qemu-img create -f qcow2 hd1.qcow2 1M $ $QEMU -drive if=none,node-name=hd0,file=hd0.qcow2,\ backing.driver=qcow2,backing.file.filename=hd1.qcow2 (qemu) qemu-io hd0 "reopen -o backing.l2-cache-size=2M" If the child does not inherit from the parent then it does not get reopened and its options cannot be changed: $ $QEMU -drive if=none,node-name=hd1,file=hd1.qcow2 -drive if=none,node-name=hd0,file=hd0.qcow2,backing=hd1 (qemu) qemu-io hd0 "reopen -o backing.l2-cache-size=2M" Cannot change the option 'backing.l2-cache-size' If a disk image has a chain of backing files then all of them are also connected through their inherits_from pointers (i.e. it's possible to walk the chain in reverse order from base to top). However this is broken if the intermediate nodes are removed using e.g. block-stream because the inherits_from pointer from the base node becomes NULL: $ qemu-img create -f qcow2 hd0.qcow2 1M $ qemu-img create -f qcow2 -b hd0.qcow2 hd1.qcow2 $ qemu-img create -f qcow2 -b hd1.qcow2 hd2.qcow2 $ $QEMU -drive if=none,file=hd2.qcow2 (qemu) qemu-io none0 "reopen -o backing.l2-cache-size=2M" (qemu) block_stream none0 0 hd0.qcow2 (qemu) qemu-io none0 "reopen -o backing.l2-cache-size=2M" Cannot change the option 'backing.l2-cache-size' This patch updates the inherits_from pointer if the intermediate nodes of a backing chain are removed using bdrv_set_backing_hd(), and adds a test case for this scenario. Signed-off-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-10-31 19:16:37 +03:00
161 rw auto quick
162 quick
163 rw
165 rw quick
169 rw migration
170 rw auto quick
171 rw quick
172 auto
173 rw
174 auto
175 quick
176 rw auto backing
tests: Add coverage for recent block geometry fixes Use blkdebug's new geometry constraints to emulate setups that have needed past regression fixes: write zeroes asserting when running through a loopback block device with max-transfer smaller than cluster size, and discard rounding away portions of requests not aligned to preferred boundaries. Also, add coverage that the block layer is honoring max transfer limits. For now, a single iotest performs all actions, with the idea that we can add future blkdebug constraint test cases in the same file; but it can be split into multiple iotests if we find reason to run one portion of the test in more setups than what are possible in the other. For reference, the final portion of the test (checking whether discard passes as much as possible to the lowest layers of the stack) works as follows: qemu-io: discard 30M at 80000001, passed to blkdebug blkdebug: discard 511 bytes at 80000001, -ENOTSUP (smaller than blkdebug's 512 align) blkdebug: discard 14371328 bytes at 80000512, passed to qcow2 qcow2: discard 739840 bytes at 80000512, -ENOTSUP (smaller than qcow2's 1M align) qcow2: discard 13M bytes at 77M, succeeds blkdebug: discard 15M bytes at 90M, passed to qcow2 qcow2: discard 15M bytes at 90M, succeeds blkdebug: discard 1356800 bytes at 105M, passed to qcow2 qcow2: discard 1M at 105M, succeeds qcow2: discard 308224 bytes at 106M, -ENOTSUP (smaller than qcow2's 1M align) blkdebug: discard 1 byte at 111457280, -ENOTSUP (smaller than blkdebug's 512 align) Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Message-id: 20170429191419.30051-10-eblake@redhat.com [mreitz: For cooperation with image locking, add -r to the qemu-io invocation which verifies the image content] Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-04-29 22:14:19 +03:00
177 rw auto quick
178 img
179 rw auto quick
181 rw auto migration quick
182 rw quick
183 rw migration quick
184 rw auto quick
185 rw
186 rw auto
187 rw auto
188 rw quick
189 rw
190 rw auto quick
191 rw auto
192 rw auto quick
194 rw migration quick
195 rw auto quick
196 rw quick migration
197 rw quick
198 rw
199 rw migration
200 rw
201 rw migration quick
202 rw quick
203 rw auto migration quick
204 rw quick
205 rw quick
206 rw
207 rw
208 rw quick
209 rw quick
210 rw
211 rw quick
212 rw quick
213 rw quick
214 rw auto
215 rw quick
216 rw quick
217 rw auto quick
218 rw quick
219 rw
220 rw auto
221 rw quick
222 rw quick
223 rw quick
224 rw quick
225 rw quick
226 auto quick
227 quick
228 rw quick
229 auto quick
231 quick
232 quick
233 quick
234 quick migration
235 quick
236 quick
237 rw quick
238 quick
239 rw quick
240 quick
241 rw quick
242 rw quick
243 rw quick
244 rw auto quick
245 rw
246 rw quick
247 rw quick
248 rw quick
249 rw auto quick
250 rw quick
251 rw auto quick
252 rw auto backing quick
253 rw quick
254 rw backing quick
255 rw quick
256 rw auto quick
257 rw
258 rw quick
259 rw auto quick
260 rw quick
261 rw
262 rw quick migration
263 rw quick
264 rw
265 rw auto quick
266 rw quick
267 rw auto quick snapshot
268 rw auto quick
iotests: Test large write request to qcow2 file Without HEAD^, the following happens when you attempt a large write request to a qcow2 file such that the number of bytes covered by all clusters involved in a single allocation will exceed INT_MAX: (A) handle_alloc_space() decides to fill the whole area with zeroes and fails because bdrv_co_pwrite_zeroes() fails (the request is too large). (B) If handle_alloc_space() does not do anything, but merge_cow() decides that the requests can be merged, it will create a too long IOV that later cannot be written. (C) Otherwise, all parts will be written separately, so those requests will work. In either B or C, though, qcow2_alloc_cluster_link_l2() will have an overflow: We use an int (i) to iterate over nb_clusters, and then calculate the L2 entry based on "i << s->cluster_bits" -- which will overflow if the range covers more than INT_MAX bytes. This then leads to image corruption because the L2 entry will be wrong (it will be recognized as a compressed cluster). Even if that were not the case, the .cow_end area would be empty (because handle_alloc() will cap avail_bytes and nb_bytes at INT_MAX, so their difference (which is the .cow_end size) will be 0). So this test checks that on such large requests, the image will not be corrupted. Unfortunately, we cannot check whether COW will be handled correctly, because that data is discarded when it is written to null-co (but we have to use null-co, because writing 2 GB of data in a test is not quite reasonable). Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-10-10 13:08:58 +03:00
270 rw backing quick
271 rw auto
272 rw
273 backing quick
274 rw backing
277 rw quick
279 rw backing quick
280 rw migration quick
281 rw quick
282 rw img quick
283 auto quick
block: always fill entire LUKS header space with zeros When initializing the LUKS header the size with default encryption parameters will currently be 2068480 bytes. This is rounded up to a multiple of the cluster size, 2081792, with 64k sectors. If the end of the header is not the same as the end of the cluster we fill the extra space with zeros. This was forgetting that not even the space allocated for the header will be fully initialized, as we only write key material for the first key slot. The space left for the other 7 slots is never written to. An optimization to the ref count checking code: commit a5fff8d4b4d928311a5005efa12d0991fe3b66f9 (refs/bisect/bad) Author: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Date: Wed Feb 27 16:14:30 2019 +0300 qcow2-refcount: avoid eating RAM made the assumption that every cluster which was allocated would have at least some data written to it. This was violated by way the LUKS header is only partially written, with much space simply reserved for future use. Depending on the cluster size this problem was masked by the logic which wrote zeros between the end of the LUKS header and the end of the cluster. $ qemu-img create --object secret,id=cluster_encrypt0,data=123456 \ -f qcow2 -o cluster_size=2k,encrypt.iter-time=1,\ encrypt.format=luks,encrypt.key-secret=cluster_encrypt0 \ cluster_size_check.qcow2 100M Formatting 'cluster_size_check.qcow2', fmt=qcow2 size=104857600 encrypt.format=luks encrypt.key-secret=cluster_encrypt0 encrypt.iter-time=1 cluster_size=2048 lazy_refcounts=off refcount_bits=16 $ qemu-img check --object secret,id=cluster_encrypt0,data=redhat \ 'json:{"driver": "qcow2", "encrypt.format": "luks", \ "encrypt.key-secret": "cluster_encrypt0", \ "file.driver": "file", "file.filename": "cluster_size_check.qcow2"}' ERROR: counting reference for region exceeding the end of the file by one cluster or more: offset 0x2000 size 0x1f9000 Leaked cluster 4 refcount=1 reference=0 ...snip... Leaked cluster 130 refcount=1 reference=0 1 errors were found on the image. Data may be corrupted, or further writes to the image may corrupt it. 127 leaked clusters were found on the image. This means waste of disk space, but no harm to data. Image end offset: 268288 The problem only exists when the disk image is entirely empty. Writing data to the disk image payload will solve the problem by causing the end of the file to be extended further. The change fixes it by ensuring that the entire allocated LUKS header region is fully initialized with zeros. The qemu-img check will still fail for any pre-existing disk images created prior to this change, unless at least 1 byte of the payload is written to. Fully writing zeros to the entire LUKS header is a good idea regardless as it ensures that space has been allocated on the host filesystem (or whatever block storage backend is used). Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20200207135520.2669430-1-berrange@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-02-07 16:55:20 +03:00
284 rw
286 rw quick
287 auto quick
288 quick
289 rw quick
290 rw auto quick
291 rw quick
292 rw auto quick
293 rw
294 rw quick
295 rw
296 rw
297 meta
299 auto quick
300 migration
301 backing quick
302 quick
303 rw quick
304 rw quick