02.10.2019 16:43, Peter Krempa wrote: > On Wed, Oct 02, 2019 at 13:11:47 +0200, Kevin Wolf wrote: >> Am 02.10.2019 um 12:46 hat Peter Krempa geschrieben: > > [...] > >>> I'd like to re-iterate that the necessity to keep node names same on >>> both sides of migration is unexpected, undocumented and in some cases >>> impossible. >> >> I think the (implicitly made) requirement is not that all node-names are >> kept the same, but only the node-names of those nodes for which >> migration transfers some state. > > [1] This also implies that node names of the nodes where migration should > not transfer state must be unique on the both sides since you can't > control it otherwise. > >> It seems to me that bitmap migration is the first case of putting >> something in the migration stream that isn't related to a frontend, but >> to the backend, so the usual device hierarchy to address information >> doesn't work here. And it seems the implications of this weren't really >> considered sufficiently, resulting in the design problem we're >> discussing now. > > This should then also be a moment to carefully think about the > semantics of migrating data for backends which don't need to be > identical on both sides of the migration for the VM to work correctly. > > I think that any feature which touches backends should ideally be an > opt-in. This would call for a explicit action to use it which would also > allow management apps to consider expectations and implications of > enabling it rather than doing it automatically. One possibility would be > also to make it introspectable in such a way that it can be made opt-in > by disabling all unknown features programatically in the mgmt app.
Currently bitmaps are migrated only if bitmaps migration capability is enabled, so it's not so bad. -- Best regards, Vladimir
