On 09/21/2017 05:11 AM, Andrea Bolognani wrote:
On Mon, 2017-09-11 at 13:22 +0200, Peter Krempa wrote:
> Please make sure that the migration stream does not depend on the
> ordering of the controllers. Re-arranging them could be a problem if we
> don't have a way to migrate them afterwards.
Took me long enough to get around to actually test this, but it
turns out you were completely spot-on: reordering controllers[1]
can indeed break migration.
2017-09-21T08:43:21.092559Z qemu-kvm: 800000020000001 != 800000020000002
2017-09-21T08:43:21.092588Z qemu-kvm: Failed to load spapr_pci:buid
2017-09-21T08:43:21.092596Z qemu-kvm: error while loading state for instance 0x1 of
device 'spapr_pci'
2017-09-21T08:43:21.093561Z qemu-kvm: load of migration failed: Invalid argument
Now, you already have to try pretty hard to get a guest in a state
where controllers are not showing up in the expected order, but
the same can be said for the situation described in the bug report
linked above...
So here's a question - if you migrate the same "misordered" controllers
between two systems that don't have these patches, does it succeed? I'm
thinking that (because the controllers are re-ordered the next time
they're parsed) the order might be changed anyway, thus it might still fail.
If it's going to fail *without* the patch anyway, then adding the patch
is actually an *improvement* in migration behavior (since at least it
will succeed when migrating from new->new (or even new->old)).
Or my theory could be completely bogus :-)
All things considered, I think it's better to avoid the risk of
breaking migration, however small it might be, even though it
means leaving other failure scenarios unaddressed.
So I guess this is will be a SNACK. That's okay, I was starting
to feel a bit hungry anyway.
Thanks for bringing up the issue!
[1] PHBs at least, not sure about others.