summaryrefslogtreecommitdiff
path: root/tests/qemu-iotests
AgeCommit message (Collapse)AuthorFilesLines
2018-05-08iotests: Add test for cancelling a mirror jobMax Reitz3-0/+169
We already have an extensive mirror test (041) which does cover cancelling a mirror job, especially after it has emitted the READY event. However, it does not check what exact events are emitted after block-job-cancel is executed. More importantly, it does not use throttling to ensure that it covers the case of block-job-cancel before READY. It would be possible to add this case to 041, but considering it is already our largest test file, it makes sense to create a new file for these cases. Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20180501220509.14152-3-mreitz@redhat.com Signed-off-by: Jeff Cody <jcody@redhat.com>
2018-05-08block/mirror: honor ratelimit againStefan Hajnoczi1-1/+1
Commit b76e4458b1eb3c32e9824fe6aa51f67d2b251748 ("block/mirror: change the semantic of 'force' of block-job-cancel") accidentally removed the ratelimit in the mirror job. Reintroduce the ratelimit but keep the block-job-cancel force=true behavior that was added in commit b76e4458b1eb3c32e9824fe6aa51f67d2b251748. Note that block_job_sleep_ns() returns immediately when the job is cancelled. Therefore it's safe to unconditionally call block_job_sleep_ns() - a cancelled job does not sleep. This commit fixes the non-deterministic qemu-iotests 185 output. The test relies on the ratelimit to make the job sleep until the 'quit' command is processed. Previously the job could complete before the 'quit' command was received since there was no ratelimit. Cc: Liang Li <liliang.opensource@gmail.com> Cc: Jeff Cody <jcody@redhat.com> Cc: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: 20180424123527.19168-1-stefanha@redhat.com Signed-off-by: Jeff Cody <jcody@redhat.com>
2018-04-16iotests: fix 169Vladimir Sementsov-Ogievskiy1-21/+27
Improve and fix 169: - use MIGRATION events instead of RESUME - make a TODO: enable dirty-bitmaps capability for offline case - recreate vm_b without -incoming near test end This (likely) fixes racy faults at least of the following types: - timeout on waiting for RESUME event - sha256 mismatch on line 136 (142 after this patch) - fail to self.vm_b.launch() on line 135 (141 now after this patch) And surely fixes cat processes, left after test finish. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-id: 20180411122606.367301-3-vsementsov@virtuozzo.com Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-04-11Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into stagingPeter Maydell7-17/+32
Block layer patches # gpg: Signature made Tue 10 Apr 2018 15:53:08 BST # gpg: using RSA key 7F09B272C88F2FD6 # gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>" # Primary key fingerprint: DC3D EB15 9A9A F95D 3D74 56FE 7F09 B272 C88F 2FD6 * remotes/kevin/tags/for-upstream: qemu-iotests: update 185 output commit/stream: Reset delay_ns qemu-iotests: Remove _supported_fmt dmg iotests: blacklist bochs and cloop for 205 and 208 iotests.py: improve verify_image_format helper hw/block/pflash_cfi: fix off-by-one error iotests.py: support unsupported_fmts in main() Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-04-10qemu-iotests: update 185 outputStefan Hajnoczi2-9/+13
Commit 4486e89c219c0d1b9bd8dfa0b1dd5b0d51ff2268 ("vl: introduce vm_shutdown()") added a bdrv_drain_all() call. As a side-effect of the drain operation the block job iterates one more time than before. The 185 output no longer matches and the test is failing now. It may be possible to avoid the superfluous block job iteration, but that type of patch is not suitable late in the QEMU 2.12 release cycle. This patch simply updates the 185 output file. The new behavior is correct, just not optimal, so make the test pass again. Fixes: 4486e89c219c0d1b9bd8dfa0b1dd5b0d51ff2268 ("vl: introduce vm_shutdown()") Cc: Kevin Wolf <kwolf@redhat.com> Cc: QingFeng Hao <haoqf@linux.vnet.ibm.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: QingFeng Hao <haoqf@linux.vnet.ibm.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-04-10qemu-iotests: Remove _supported_fmt dmgKevin Wolf2-2/+2
qemu-iotests doesn't support dmg, and the dmg block driver doesn't support image creation. Two test cases declare dmg as supported, but that's obviously wrong for both reasons. Remove the declaration. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2018-04-10iotests: blacklist bochs and cloop for 205 and 208Vladimir Sementsov-Ogievskiy2-1/+3
Blacklist these formats, as they don't support image creation, as they say: > ./qemu-img create -f bochs x 1m qemu-img: x: Format driver 'bochs' does not support image creation > ./qemu-img create -f cloop x 1m qemu-img: x: Format driver 'cloop' does not support image creation Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-04-10iotests.py: improve verify_image_format helperVladimir Sementsov-Ogievskiy1-3/+11
Support "generic" formats like in bash tests with their _supported_fmt generic The test, supporting "generic" formats will run if IMGFMT_GENERIC = true, which is default, except for bochs and cloop. However, you can use verify_image_format(['generic', 'bochs']), which will run for all except cloop (for this moment). Also, add an assert (we don't want set both arguments) and remove duplication. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-04-10iotests.py: support unsupported_fmts in main()Vladimir Sementsov-Ogievskiy1-2/+3
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-04-10iotests: fix wait_until_completed()Peter Xu1-6/+3
If there are more than one events, wait_until_completed() might return the 2nd event even if the 1st event is JOB_COMPLETED, since the for loop will continue to run even if completed is set to True. It never happened before, but it can be triggered when OOB is enabled due to the RESUME startup message. Fix that up. Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20180408030542.17855-1-peterx@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Eric Blake <eblake@redhat.com>
2018-04-03Merge remote-tracking branch 'mreitz/tags/pull-block-2018-04-03' into ↵Kevin Wolf6-2/+117
queue-block A fix for preallocated truncation, a new iotest, and a fix to make the iotests work more comfortably on ppc64 # gpg: Signature made Tue Apr 3 17:40:57 2018 CEST # gpg: using RSA key F407DB0061D5CF40 # gpg: Good signature from "Max Reitz <mreitz@redhat.com>" # Primary key fingerprint: 91BE B60A 30DB 3E88 57D1 1829 F407 DB00 61D5 CF40 * mreitz/tags/pull-block-2018-04-03: iotests: Test abnormally large size in compressed cluster descriptor qemu-iotests: Use ppc64 qemu_arch on ppc64le host iotests: Test preallocated truncate of 2G image block/file-posix: Fix fully preallocated truncate Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-04-03iotests: Test abnormally large size in compressed cluster descriptorAlberto Garcia2-0/+80
L2 entries for compressed clusters have a field that indicates the number of sectors used to store the data in the image. That's however not the size of the compressed data itself, just the number of sectors where that data is located. The actual data size is usually not a multiple of the sector size, and therefore cannot be represented with this field. The way it works is that QEMU reads all the specified sectors and starts decompressing the data until there's enough to recover the original uncompressed cluster. If there are any bytes left that haven't been decompressed they are simply ignored. One consequence of this is that even if the size field is larger than it needs to be QEMU can handle it just fine: it will read more data from disk but it will ignore the extra bytes. This test creates an image with two compressed clusters that use 5 sectors (2.5 KB) each, increases the size field to the maximum (8192 sectors, or 4 MB) and verifies that the data can be read without problems. This test is important because while the decompressed data takes exactly one cluster, the maximum value allowed in the compressed size field is twice the cluster size. So although QEMU won't produce images with such large values we need to make sure that it can handle them. Another effect of increasing the size field is that it can make it include data from the following host cluster(s). In this case 'qemu-img check' will detect that the refcounts are not correct, and we'll need to rebuild them. Additionally, this patch also tests that decreasing the size corrupts the image since the original data can no longer be recovered. In this case QEMU returns an error when trying to read the compressed data, but 'qemu-img check' doesn't see anything wrong if the refcounts are consistent. One possible task for the future is to make 'qemu-img check' verify the sizes of the compressed clusters, by trying to decompress the data and checking that the size stored in the L2 entry is correct. Signed-off-by: Alberto Garcia <berto@igalia.com> Message-id: 20180329120745.11154-1-berto@igalia.com Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-04-03qemu-iotests: Use ppc64 qemu_arch on ppc64le hostLukáš Doktor2-2/+3
The qemu target does not always correspond to the host machine type. For example ppc64le machine target is ppc64. Let's introduce "qemu_arch" variable to store the matching qemu architecture related to the current architecture and use it when auto-detecting the default qemu binary. Signed-off-by: Lukáš Doktor <ldoktor@redhat.com> Message-id: 20180329112053.5399-2-ldoktor@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-04-03iotests: Test preallocated truncate of 2G imageMax Reitz2-0/+34
Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20180228131315.30194-3-mreitz@redhat.com Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-04-03iotests: fix 208 for luks formatVladimir Sementsov-Ogievskiy1-1/+1
Support luks images creatins like in 205 Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-04-03iotests: Update 186 after commit ac64273c66ab136c44043259162Alberto Garcia3-29/+34
Commit ac64273c66ab136c44 modified the output of iotest 186, changing the QOM path of floppy drives from /machine/unattached/device[17] to /machine/unattached/device[13]. Instead of updating the test output to reflect this change, this patch adds a new filter that hides all QOM paths from the 'Attached to:' line of the 'info block' command. Signed-off-by: Alberto Garcia <berto@igalia.com> Cc: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-04-03iotests: Update 051 and 186 after commit 1454509726719e0933cAlberto Garcia3-52/+0
SCSI controllers are no longer created automatically for -drive if=scsi, so this patch updates the tests that relied on that. Signed-off-by: Alberto Garcia <berto@igalia.com> Reviewed-by: Eric Blake <eblake@redhat.com> Cc: Thomas Huth <thuth@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-03-27Merge remote-tracking branch 'remotes/maxreitz/tags/pull-block-2018-03-26' ↵Peter Maydell2-7/+5
into staging A fix for dirty bitmap migration through shared storage, and a VMDK patch keeping us from creating too large extents. # gpg: Signature made Mon 26 Mar 2018 21:17:05 BST # gpg: using RSA key F407DB0061D5CF40 # gpg: Good signature from "Max Reitz <mreitz@redhat.com>" # Primary key fingerprint: 91BE B60A 30DB 3E88 57D1 1829 F407 DB00 61D5 CF40 * remotes/maxreitz/tags/pull-block-2018-03-26: vmdk: return ERROR when cluster sector is larger than vmdk limitation iotests: enable shared migration cases in 169 qcow2: fix bitmaps loading when bitmaps already exist qcow2-bitmap: add qcow2_reopen_bitmaps_rw_hint() Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-03-26iotests: enable shared migration cases in 169Vladimir Sementsov-Ogievskiy2-7/+5
Shared migration for dirty bitmaps is fixed by previous patches, so we can enable the test. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-id: 20180320170521.32152-5-vsementsov@virtuozzo.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-03-26qemu-iotests: Test vhdx image creation with QMPKevin Wolf3-0/+471
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-03-26qemu-iotests: Test parallels image creation with QMPKevin Wolf3-0/+438
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-03-26qemu-iotests: Test invalid resize on luksKevin Wolf2-0/+53
This tests that the .bdrv_truncate implementation for luks doesn't crash for invalid image sizes. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2018-03-26qemu-iotests: Enable 025 for luksKevin Wolf1-1/+8
We want to test resizing even for luks. The only change that is needed is to explicitly zero out new space for luks because it's undefined. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2018-03-26qemu-iotests: Test vdi image creation with QMPKevin Wolf3-0/+344
Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2018-03-26qcow2: Reset free_cluster_index when allocating a new refcount blockAlberto Garcia3-3/+33
When we try to allocate new clusters we first look for available ones starting from s->free_cluster_index and once we find them we increase their reference counts. Before we get to call update_refcount() to do this last step s->free_cluster_index is already pointing to the next cluster after the ones we are trying to allocate. During update_refcount() it may happen however that we also need to allocate a new refcount block in order to store the refcounts of these new clusters (and to complicate things further that may also require us to grow the refcount table). After all this we don't know if the clusters that we originally tried to allocate are still available, so we return -EAGAIN to ask the caller to restart the search for free clusters. This is what can happen in a common scenario: 1) We want to allocate a new cluster and we see that cluster N is free. 2) We try to increase N's refcount but all refcount blocks are full, so we allocate a new one at N+1 (where s->free_cluster_index was pointing at). 3) Once we're done we return -EAGAIN to look again for a free cluster, but now s->free_cluster_index points at N+2, so that's the one we allocate. Cluster N remains unallocated and we have a hole in the qcow2 file. This can be reproduced easily: qemu-img create -f qcow2 -o cluster_size=512 hd.qcow2 1M qemu-io -c 'write 0 124k' hd.qcow2 After this the image has 132608 bytes (256 clusters), and the refcount block is full. If we write 512 more bytes it should allocate two new clusters: the data cluster itself and a new refcount block. qemu-io -c 'write 124k 512' hd.qcow2 However the image has now three new clusters (259 in total), and the first one of them is empty (and unallocated): dd if=hd.qcow2 bs=512c skip=256 count=1 | hexdump -C If we write larger amounts of data in the last step instead of the 512 bytes used in this example we can create larger holes in the qcow2 file. What this patch does is reset s->free_cluster_index to its previous value when alloc_refcount_block() returns -EAGAIN. This way the caller will try to allocate again the original clusters if they are still free. The output of iotest 026 also needs to be updated because now that images have no holes some tests fail at a different point and the number of leaked clusters is different. Signed-off-by: Alberto Garcia <berto@igalia.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-03-26iotests: 163 is not quickEric Blake1-1/+1
Testing on ext4, most 'quick' qcow2 tests took less than 5 seconds, but 163 took more than 20. Let's remove it from the quick set. Signed-off-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-03-19block: Handle null backing linkMax Reitz2-0/+28
Instead of converting all "backing": null instances into "backing": "", handle a null value directly in bdrv_open_inherit(). This enables explicitly null backing links for json:{} filenames. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Message-Id: <20180224154033.29559-7-mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> [eblake: rebase to qobject_to() parameter order and qapi headers split] Signed-off-by: Eric Blake <eblake@redhat.com>
2018-03-19iotests: Avoid realpath, for CentOS 6Eric Blake1-6/+6
CentOS 6 lacks a realpath binary on the base install, which makes all iotests runs fail since the 2.11 release: 001 - output mismatch (see 001.out.bad) ./check: line 815: realpath: command not found diff: missing operand after `/home/dummy/qemu/tests/qemu-iotests/001.out' diff: Try `diff --help' for more information. Many of the uses of 'realpath' in the check script were being used on the output of 'type -p' - but that is already an absolute file name. While a canonical name can often be shorter (realpath gets rid of /../), it can also be longer (due to symlink expansion); and we really don't care if the name is canonical, merely that it was an executable file with an absolute path. These were broken in commit cceaf1db. The remaining use of realpath was to convert a possibly relative filename into an absolute one before calling diff to make it easier to copy-and-paste the filename for moving the .bad file into place as the new reference file even when running iotests out-of-tree (see commit 93e53fb6), but $PWD can achieve the same purpose. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-03-19block: fix iotest 146 output expectationsJeff Cody1-1/+1
Commit bff5554843 added "force_size" into the common.filter for _filter_img_create(), but test 146 still expects it in the output. Signed-off-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-03-19qemu-iotests: Enable write tests for parallelsKevin Wolf2-2/+1
Originally we added parallels as a read-only format to qemu-iotests where we did just some tests with a binary image. Since then, write and image creation support has been added to the driver, so we can now enable it in _supported_fmt generic. The driver doesn't support migration yet, though, so we need to add it to the list of exceptions in 181. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com>
2018-03-19iotests: Add regression test for commit base lockingFam Zheng2-0/+17
Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-03-19qemu-iotests: Test luks QMP image creationKevin Wolf4-1/+348
Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2018-03-19iotests: test manual job dismissalJohn Snow2-2/+189
Signed-off-by: John Snow <jsnow@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-03-19blockjobs: Expose manual propertyJohn Snow1-12/+12
Expose the "manual" property via QAPI for the backup-related jobs. As of this commit, this allows the management API to request the "concluded" and "dismiss" semantics for backup jobs. Signed-off-by: John Snow <jsnow@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-03-19iotests: add pause_waitJohn Snow3-19/+16
Split out the pause command into the actual pause and the wait. Not every usage presently needs to resubmit a pause request. The intent with the next commit will be to explicitly disallow redundant or meaningless pause/resume requests, so the tests need to become more judicious to reflect that. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-03-19blockjobs: add status enumJohn Snow1-12/+12
We're about to add several new states, and booleans are becoming unwieldly and difficult to reason about. It would help to have a more explicit bookkeeping of the state of blockjobs. To this end, add a new "status" field and add our existing states in a redundant manner alongside the bools they are replacing: UNDEFINED: Placeholder, default state. Not currently visible to QMP unless changes occur in the future to allow creating jobs without starting them via QMP. CREATED: replaces !!job->co && paused && !busy RUNNING: replaces effectively (!paused && busy) PAUSED: Nearly redundant with info->paused, which shows pause_count. This reports the actual status of the job, which almost always matches the paused request status. It differs in that it is strictly only true when the job has actually gone dormant. READY: replaces job->ready. STANDBY: Paused, but job->ready is true. New state additions in coming commits will not be quite so redundant: WAITING: Waiting on transaction. This job has finished all the work it can until the transaction converges, fails, or is canceled. PENDING: Pending authorization from user. This job has finished all the work it can until the job or transaction is finalized via block_job_finalize. This implies the transaction has converged and left the WAITING phase. ABORTING: Job has encountered an error condition and is in the process of aborting. CONCLUDED: Job has ceased all operations and has a return code available for query and may be dismissed via block_job_dismiss. NULL: Job has been dismissed and (should) be destroyed. Should never be visible to QMP. Some of these states appear somewhat superfluous, but it helps define the expected flow of a job; so some of the states wind up being synchronous empty transitions. Importantly, jobs can be in only one of these states at any given time, which helps code and external users alike reason about the current condition of a job unambiguously. Signed-off-by: John Snow <jsnow@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-03-16Merge remote-tracking branch 'remotes/jnsnow/tags/bitmaps-pull-request' into ↵Peter Maydell6-1/+292
staging # gpg: Signature made Tue 13 Mar 2018 21:11:43 GMT # gpg: using RSA key 7DEF8106AAFC390E # gpg: Good signature from "John Snow (John Huston) <jsnow@redhat.com>" # Primary key fingerprint: FAEB 9711 A12C F475 812F 18F2 88A9 064D 1835 61EB # Subkey fingerprint: F9B7 ABDB BCAC DF95 BE76 CBD0 7DEF 8106 AAFC 390E * remotes/jnsnow/tags/bitmaps-pull-request: iotests: add dirty bitmap postcopy test iotests: add dirty bitmap migration test migration: add postcopy migration of dirty bitmaps migration: allow qmp command migrate-start-postcopy for any postcopy migration: add is_active_iterate handler migration/qemu-file: add qemu_put_counted_string() migration: include migrate_dirty_bitmaps in migrate_postcopy qapi: add dirty-bitmaps migration capability migration: introduce postcopy-only pending dirty-bitmap: add locked state block/dirty-bitmap: add _locked version of bdrv_reclaim_dirty_bitmap block/dirty-bitmap: fix locking in bdrv_reclaim_dirty_bitmap block/dirty-bitmap: add bdrv_dirty_bitmap_enable_successor() Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-03-13iotests: add dirty bitmap postcopy testVladimir Sementsov-Ogievskiy4-1/+130
Test - start two vms (vm_a, vm_b) - in a - do writes from set A - do writes from set B - fix bitmap sha256 - clear bitmap - do writes from set A - start migration - than, in b - wait vm start (postcopy should start) - do writes from set B - check bitmap sha256 The test should verify postcopy migration and then merging with delta (changes in target, during postcopy process). Reduce supported cache modes to only 'none', because with cache on time from source.STOP to target.RESUME is unpredictable and we can fail with timout while waiting for target.RESUME. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-id: 20180313180320.339796-14-vsementsov@virtuozzo.com
2018-03-13iotests: add dirty bitmap migration testVladimir Sementsov-Ogievskiy3-0/+162
The test starts two vms (vm_a, vm_b), create dirty bitmap in the first one, do several writes to corresponding device and then migrate vm_a to vm_b. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-id: 20180313180320.339796-13-vsementsov@virtuozzo.com
2018-03-13iotests: new test 209 for NBD BLOCK_STATUSVladimir Sementsov-Ogievskiy3-0/+37
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20180312152126.286890-9-vsementsov@virtuozzo.com> Signed-off-by: Eric Blake <eblake@redhat.com>
2018-03-13iotests: add file_path helperVladimir Sementsov-Ogievskiy1-0/+32
Simple way to have auto generated filenames with auto cleanup. Like FilePath but without using 'with' statement and without additional indentation of the whole test. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20180312152126.286890-8-vsementsov@virtuozzo.com> Reviewed-by: Eric Blake <eblake@redhat.com> [eblake: grammar tweak] Signed-off-by: Eric Blake <eblake@redhat.com>
2018-03-13iotests.py: tiny refactor: move system imports upVladimir Sementsov-Ogievskiy1-2/+3
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20180312152126.286890-7-vsementsov@virtuozzo.com> Signed-off-by: Eric Blake <eblake@redhat.com>
2018-03-13iotests: add 208 nbd-server + blockdev-snapshot-sync test caseStefan Hajnoczi3-0/+65
This test case adds an NBD server export and then invokes blockdev-snapshot-sync, which changes the BlockDriverState node that the NBD server's BlockBackend points to. This is an interesting scenario to test and exercises the code path fixed by the previous commit. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20180306204819.11266-3-stefanha@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Eric Blake <eblake@redhat.com>
2018-03-13iotests: Fix stuck NBD process on 33Eric Blake1-0/+1
Commit afe35cde6 added additional actions to test 33, but forgot to reset the image between tests. As a result, './check -nbd 33' fails because the qemu-nbd process from the first half is still occupying the port, preventing the second half from starting a new qemu-nbd process. Worse, the failure leaves a rogue qemu-nbd process behind even after the test fails, which causes knock-on failures to later tests that also want to start qemu-nbd. Reported-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20180312211156.452139-1-eblake@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2018-03-09qemu-iotests: fix 203 migration completion raceStefan Hajnoczi2-4/+16
There is a race between the test's 'query-migrate' QMP command after the QMP 'STOP' event and completing the migration: The test case invokes 'query-migrate' upon receiving 'STOP'. At this point the migration thread may still be in the process of completing. Therefore 'query-migrate' can return 'status': 'active' for a brief window of time instead of 'status': 'completed'. This results in qemu-iotests 203 hanging. Solve the race by enabling the 'events' migration capability, which causes QEMU to emit migration-specific QMP events that do not suffer from this race condition. Wait for the QMP 'MIGRATION' event with 'status': 'completed'. Reported-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: 20180305155926.25858-1-stefanha@redhat.com Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-03-09iotests: Tweak 030 in order to trigger a race condition with parallel jobsAlberto Garcia2-11/+45
This patch tweaks TestParallelOps in iotest 030 so it allocates data in smaller regions (256KB/512KB instead of 512KB/1MB) and the block-stream job in test_stream_commit() only needs to copy data that is at the very end of the image. This way when the block-stream job is awakened it will finish right away without any chance of being stopped by block_job_sleep_ns(). This triggers the bug that was fixed by 3d5d319e1221082974711af1d09d82f and 1a63a907507fbbcfaee3f622907ec24 and is therefore a more useful test case for parallel block jobs. After this patch the aforementiond bug can also be reproduced with the test_stream_parallel() test case. Since with this change the stream job in test_stream_commit() finishes early, this patch introduces a similar test case where both jobs are slowed down so they can actually run in parallel. Signed-off-by: Alberto Garcia <berto@igalia.com> Cc: John Snow <jsnow@redhat.com> Message-id: 20180306130121.30243-1-berto@igalia.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-03-09iotests: Skip test for ENOMEM errorFam Zheng1-3/+2
The AFL image is to exercise the code validating image size, which doesn't work on 32 bit or when out of memory (there is a large allocation before the interesting point). So check that and skip the test, instead of faking the result. Signed-off-by: Fam Zheng <famz@redhat.com> Message-id: 20180301011413.11531-1-famz@redhat.com Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-03-09iotests: Mark all tests executableEric Blake10-0/+0
The majority of our iotests have the executable bit set; fix the few outliers for consistency. Signed-off-by: Eric Blake <eblake@redhat.com> Message-id: 20180305161824.7188-1-eblake@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-03-09iotests: Test creating overlay when guest runningFam Zheng2-6/+9
Signed-off-by: Fam Zheng <famz@redhat.com> Message-id: 20171225025107.23985-1-famz@redhat.com Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-03-09qemu-iotests: Test ssh image creation over QMPKevin Wolf3-0/+337
Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>