[libvirt] [PATCH 2/2] qemu: Order PCI controllers on the command line

[Laine Stump]

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.