On 28.02.21 21:43, Michael S. Tsirkin wrote: > Sure. The way to do that is to tie old behaviour to old machine > versions. We'll need it in stable too ...
Yeah, using machine types is how its meant to be with solving migration breakage, sure. But that means we have to permanently pin the VM, and any backup restored from that to that machine type *forever*. That'd be new for us as we always could allow a newer machine type for a fresh start (i.e., non migration or the like) here, and mean that lots of other improvements guarded by a newer machine type for those VMs will. Why not a switch + machine type, solves migration and any special cases of it but also allows machine updates but also to keep the old behavior? And yeah, stable is wanted, but extrapolating from the current stable releases frequency, where normally there's maximal one after 5-6 months from the .0 release, means that this will probably still hit all those distributions I mentioned or is there something more soon planned? Also, is there any regression testing infrastructure around to avoid such changes in the future? This change got undetected for 7 months, which can be pretty the norm for QEMU releases, so some earlier safety net would be good? Is there anything which dumps various default machine HW layouts and uses them for an ABI check of some sorts?
