Re: [PATCH 4/7] iotests/129: Use throttle node

[Max Reitz <mreitz@redhat.com>]

On 13.01.21 15:06, Max Reitz wrote:
> Throttling on the BB has not affected block jobs in a while, so it is
> possible that one of the jobs in 129 finishes before the VM is stopped.
> We can fix that by running the job from a throttle node.
> 
> Signed-off-by: Max Reitz <mreitz@redhat.com>
> ---
>   tests/qemu-iotests/129 | 39 +++++++++++++++------------------------
>   1 file changed, 15 insertions(+), 24 deletions(-)
> 
> diff --git a/tests/qemu-iotests/129 b/tests/qemu-iotests/129
> index dd23bb2e5a..febc806398 100755
> --- a/tests/qemu-iotests/129
> +++ b/tests/qemu-iotests/129

[...]

> @@ -53,33 +51,26 @@ class TestStopWithBlockJob(iotests.QMPTestCase):
>       def do_test_stop(self, cmd, **args):
>           """Test 'stop' while block job is running on a throttled drive.
>           The 'stop' command shouldn't drain the job"""
> -        params = {"device": "drive0",
> -                  "bps": 1024,
> -                  "bps_rd": 0,
> -                  "bps_wr": 0,
> -                  "iops": 0,
> -                  "iops_rd": 0,
> -                  "iops_wr": 0,
> -                 }
> -        result = self.vm.qmp("block_set_io_throttle", conv_keys=False,
> -                             **params)
> -        self.assert_qmp(result, 'return', {})
>           result = self.vm.qmp(cmd, **args)
>           self.assert_qmp(result, 'return', {})
> +
>           result = self.vm.qmp("stop")
>           self.assert_qmp(result, 'return', {})
>           result = self.vm.qmp("query-block-jobs")
> +
>           self.assert_qmp(result, 'return[0]/status', 'running')
>           self.assert_qmp(result, 'return[0]/ready', False)
>   
> +        self.vm.qmp("block-job-cancel", device="drive0", force=True)
> +

Sorry, somewhere along the way I forgot to remove this block-job-cancel. 
  It’s still from
https://lists.nongnu.org/archive/html/qemu-block/2019-06/msg00499.html 
and I don’t know why I added it there.  It should probably go.

('stop' should have drained, that’s the point, so there shouldn’t be any 
further delay if we quit the VM without cancelling the job.)

Max