On Fri, Nov 08, 2019 at 06:38:17PM +0000, Dr. David Alan Gilbert wrote:
Hi Jens,
the unplug failover stuff is triggering an assertion occasionally on
aarch64; but
a) I'm not sure the right way to fix it
b) And I'm out for a little over a week
so...
I'll take care of it.
* no-re...@patchew.org (no-re...@patchew.org) wrote:
Patchew URL:
https://patchew.org/QEMU/20191108104307.125020-1-dgilb...@redhat.com/
Hi,
This series failed the docker-quick@centos7 build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
make docker-image-centos7 V=1 NETWORK=1
time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1
=== TEST SCRIPT END ===
TEST check-unit: tests/test-bdrv-drain
wait_for_migration_fail: unexpected status status=wait-unplug allow_active=1
In tests/migration-test.c we've got wait_for_migration_fail, and it's
expecting the state to be any one of:
setup, failed or maybe active
but it's getting surprised by seeing a 'wait-unplug'
So the question is should we see a wait-unplug?
the migration code has:
if (qemu_savevm_nr_failover_devices()) {
migrate_set_state(&s->state, MIGRATION_STATUS_SETUP,
MIGRATION_STATUS_WAIT_UNPLUG);
Should qemu_savevm_nr_failover_devices() be true?
On aarch64 it seems to have a virtio-net device by default
and qemu_savevm_nr_failover_devices() checks for devices
having dev_unplug_pending but doesn't call it.
I see two fixes but am not sure which is right:
a) Add 'wait-unplug' to the wait_for_migration_fail
(easy)
b) Actually call dev_unplug_pending in qemu_savevm_nr_failover_devices
so that on a guest which has a virtio-net, but no failover device,
the state isn't entered.
I also prefer b over a, but I should only set up dev_unplug_pending when
failover=on to avoid this. I'll send a patch.
regards
Jens
