On Mon, Nov 16, 2020 at 11:41:25AM +0000, Daniel P. Berrangé wrote: > > It is possible to simplify the problem, but we'll lose freedom. For > > example, hard coding knowledge of the device implementation into the > > management tool eliminates the need for a general migration checking > > algorithm. Or we might be able to simplify it by explicitly not > > supporting cross-device implementation migration (although that would > > place stricter rules on what a new version of an existing device can > > change in order to preserve migration compatibility). > > Is migrating between 2 different vendors' impls of the same core > device spec really a thing that's needed ?
If there's intent to have this supercede vhost-user then certainly. Same I'm guessing for NVMe. > > I have doubts that these trade-offs can be made without losing support > > for use cases that are necessary. > > >From my POV, the key goal is that it should be possible to migrate > between two hosts without needing to check every single possible > config parameter that the device supports. It should only be neccessary > to check the parameters that are actually changed from their default > values. Then there just needs to be some simple string parameter that > encodes a particular set of devices, akin to the versioned machine > type. > > Applications that want to migration between cross-vendor device impls > could opt-in to checking every single little parameter, but most can > just stick with a much simplified view where they only have to check > the parameters that they've actually overriden/exposed. > > Regards, > Daniel It's a problem even for a single vendor. And we have lots of experience telling us it's a messy, difficult one. Just punting and saying vendors will do the right thing will not lead to quality implementations. > -- > |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
