On Wed, Nov 11, 2020 at 03:48:50PM +0000, Daniel P. Berrangé wrote: > On Wed, Nov 11, 2020 at 02:36:15PM +0000, Stefan Hajnoczi wrote: > > On Tue, Nov 10, 2020 at 12:12:31PM +0100, Paolo Bonzini wrote: > > > On 10/11/20 10:53, Stefan Hajnoczi wrote: > In terms of validation I can't help but feel the whole proposal is > really very complicated. > > In validating QEMU migration compatibility we merely compare the > versioned machine type. > > IIUC, in this proposal, it would be more like exploding the machine > type into all its 100's of properties and then comparing each one > individually. > > I really prefer the simpler model of QEMU versioned machine types > where compatibility is a simple string comparison, hiding the > 100's of individual config parameters. > > Of course there are scenarios where this will lead a mgmt app to > refuse a migration, when it could in fact have permitted it. > > eg consider pc-i440fx-4.0 and pc-i440fx-5.0 machine types, > which only differ in the value "foo=7" and "foo=8" respectively. > > Now if the target only supported machine type pc-i440fx-5.0, then > with a basic string comparison of machine type versin, we can't > migrate from a host uing pc-i440fx-4.0 > > If we exploded the machine type into its params, we could see that > we can migrate from pc-i440fx-4.0 to pc-i440fx-5.0, simply by > overriding the value of "foo". > > So, yes, dealing with individual params is more flexible, but it > comes at an enourmous cost in complexity to process all the > parameters. I'm not convinced this is a good tradeoff.
A single standard version number is not enough since there are optional features and resource capacity (number of queues, memory sizes, etc) varies between implementations. At best, a version number can summarize multiple migration parameters, but it cannot eliminate all of them. If we don't care about checking compatiblity ahead of time then we can use just a device model and version, but then migration fails when the source and destination end up being incompatible. Since you raised the requirement of checking migration compatibility ahead of time, I don't see a way to avoid the complexity. Stefan
signature.asc
Description: PGP signature
