Re: [PATCH v2] iotests.py: Let wait_migration wait even more

[Max Reitz]

On 20.12.19 11:07, Kevin Wolf wrote:
> Am 20.12.2019 um 10:52 hat Max Reitz geschrieben:
>> On 20.12.19 10:32, Kevin Wolf wrote:
>>> Am 19.12.2019 um 19:36 hat Max Reitz geschrieben:
>>>> The "migration completed" event may be sent (on the source, to be
>>>> specific) before the migration is actually completed, so the VM runstate
>>>> will still be "finish-migrate" instead of "postmigrate".  So ask the
>>>> users of VM.wait_migration() to specify the final runstate they desire
>>>> and then poll the VM until it has reached that state.  (This should be
>>>> over very quickly, so busy polling is fine.)
>>>>
>>>> Without this patch, I see intermittent failures in the new iotest 280
>>>> under high system load.  I have not yet seen such failures with other
>>>> iotests that use VM.wait_migration() and query-status afterwards, but
>>>> maybe they just occur even more rarely, or it is because they also wait
>>>> on the destination VM to be running.
>>>>
>>>> Signed-off-by: Max Reitz <address@hidden>
>>>
>>>> diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
>>>> index 13fd8b5cd2..0b62c42851 100644
>>>> --- a/tests/qemu-iotests/iotests.py
>>>> +++ b/tests/qemu-iotests/iotests.py
>>>> @@ -668,12 +668,16 @@ class VM(qtest.QEMUQtestMachine):
>>>>              }
>>>>          ]))
>>>>  
>>>> -    def wait_migration(self):
>>>> +    def wait_migration(self, expect_runstate):
>>>>          while True:
>>>>              event = self.event_wait('MIGRATION')
>>>>              log(event, filters=[filter_qmp_event])
>>>>              if event['data']['status'] == 'completed':
>>>>                  break
>>>> +        # The event may occur in finish-migrate, so wait for the expected
>>>> +        # post-migration runstate
>>>
>>> That's a bit too specific now that you have expect_runstate.
>>
>> Can you be more specific? :-)
>>
>> If you mean the fact of mentioning “post-migration runstate”, I simply
>> meant that as “the runstate after the migration”.  The specific runstate
>> on the source VM is called “postmigrate”.
> 
> Oh, yes, "postmigrate" is what I had in mind.
> 
>> I wouldn’t mind changing it to “after-migration runstate” or something
>> similar, if that’s what you mean.
> 
> "runstate after migration"?

Sure.

(Now you got me to wonder what permutations are permissible.  “migration
after runstate” isn’t.  “runstate migration after” is just garbage.  So
probebly on RAM and AMR.)

Max

signature.asc
Description: OpenPGP digital signature