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. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
