aboutsummaryrefslogtreecommitdiff
path: root/tests/qemu-iotests/219
AgeCommit message (Collapse)Author
2020-05-05iotests: add script_initializeJohn Snow
Like script_main, but doesn't require a single point of entry. Replace all existing initialization sections with this drop-in replacement. This brings debug support to all existing script-style iotests. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Message-Id: <20200331000014.11581-12-jsnow@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> [mreitz: Give 274 the same treatment] Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-02-07tests/qemu-iotests: Explicit usage of Python3 (scripts without __main__)Philippe Mathieu-Daudé
Use the program search path to find the Python 3 interpreter. Patch created mechanically by running: $ sed -i "s,^#\!/usr/bin/\(env\ \)\?python$,#\!/usr/bin/env python3," \ $(git grep -lF '#!/usr/bin/env python' \ | xargs grep -L 'if __name__.*__main__') Reported-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Suggested-by: Daniel P. Berrangé <berrange@redhat.com> Suggested-by: Stefan Hajnoczi <stefanha@redhat.com> Acked-by: Stefan Hajnoczi <stefanha@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200130163232.10446-11-philmd@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-01-27blockdev: unify qmp_drive_backup and drive-backup transaction pathsSergio Lopez
Issuing a drive-backup from qmp_drive_backup takes a slightly different path than when it's issued from a transaction. In the code, this is manifested as some redundancy between do_drive_backup() and drive_backup_prepare(). This change unifies both paths, merging do_drive_backup() and drive_backup_prepare(), and changing qmp_drive_backup() to create a transaction instead of calling do_backup_common() direcly. As a side-effect, now qmp_drive_backup() is executed inside a drained section, as it happens when creating a drive-backup transaction. This change is visible from the user's perspective, as the job gets paused and immediately resumed before starting the actual work. Also fix tests 141, 185 and 219 to cope with the extra JOB_STATUS_CHANGE lines. Signed-off-by: Sergio Lopez <slp@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-06-14iotests: Fix intermittent failure in 219Max Reitz
In 219, we wait for the job to make progress before we emit its status. This makes the output reliable. We do not wait for any more progress if the job's current-progress already matches its total-progress. Unfortunately, there is a bug: Right after the job has been started, it's possible that total-progress is still 0. In that case, we may skip the first progress-making step and keep ending up 64 kB short. To fix that bug, we can simply wait for total-progress to reach 4 MB (the image size) after starting the job. Reported-by: Karen Mezick <kmezick@redhat.com> Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1686651 Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20190516161114.27596-1-mreitz@redhat.com Reviewed-by: John Snow <jsnow@redhat.com> [mreitz: Adjusted commit message as per John's proposal] Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-06-11iotests: Fix 219's timingMax Reitz
219 has two issues that may lead to sporadic failure, both of which are the result of issuing query-jobs too early after a job has been modified. This can then lead to different results based on whether the modification has taken effect already or not. First, query-jobs is issued right after the job has been created. Besides its current progress possibly being in any random state (which has already been taken care of), its total progress too is basically arbitrary, because the job may not yet have been able to determine it. This patch addresses this by just filtering the total progress, like what has been done for the current progress already. However, for more clarity, the filtering is changed to replace the values by a string 'FILTERED' instead of deleting them. Secondly, query-jobs is issued right after a job has been resumed. The job may or may not yet have had the time to actually perform any I/O, and thus its current progress may or may not have advanced. To make sure it has indeed advanced (which is what the reference output already assumes), keep querying it until it has. Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20180606190628.8170-1-mreitz@redhat.com Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-05-23qemu-iotests: Test job-* with block jobsKevin Wolf
This adds a test case that tests the new job-* QMP commands with mirror and backup block jobs. Signed-off-by: Kevin Wolf <kwolf@redhat.com>