On Mon, Jan 29, 2024 at 10:44:46AM -0300, Fabiano Rosas wrote: > > Since we're at it, I would also like to know how you think about whether we > > should still suggest people using VMSD versioning, as we know that it won't > > work for backward migrations. > > > > My current thoughts is it is still fine, as it's easier to use, and it > > should still be applicable to the cases where a strict migration semantics > > are not required. However it's hard to justify which device needs that > > strictness. > > I'd prefer if we kept things strict. However I don't think we can do > that without having enough testing and specially, clear recipes on how > to add compatibility back once it gets lost. Think of that recent thread
If it was broken, IMHO we should just fix it and backport to stable. I think Juan used to worry on what happens if someone already used an old version of old release, e.g., someone using 8.2.0 may not be able to migrate to 8.2.1 if we fix that breakage in 9.0 and backport that to 8.2.1. My take is that maybe that's overcomplicated, and maybe we should simply only maintain the latest stable version, rather than all. In this case, IMHO it will be less burden if we only guarantee 8.2.1 will be working, e.g., when migrating from 8.1.z -> 8.2.1. Then we should just state a known issue in 8.2.0 that it is broken, and both: (1) 8.1.z -> 8.2.0, and (2) 8.2.0 -> 8.2.1 will expect to fail. > were we discussed an old powerpc issue. How come we can see the fix > today in the code but cannot tell which problem it was trying to solve? > That's bonkers. Ideally every type of breakage would have a mapping into > why it breaks and how to fix it. > > So with testing to catch the issue early and a clear step-by-step on how > to identify and fix compatibility, then we could require strict > compatibility for every device. I don't think we can guarantee no bug there, but indeed we can do better on providing some test framework for device VMSDs. > > > > > For example, any device to be used in migration-test must be forward + > > backward migration compatible at least, because you just added the n-1 > > regression tests to cover both directions. Said that, only a few devices > > are involved because currently our migration-test qemu cmdline is pretty > > simple. > > We might want to make a distinction between migration core vs. device > state testing. I see n-1 testing more like migration core testing. It's > bad to break migration, but it's really bad to break migration for > everyone because we refactored something deep within migration/. > > I also wouldn't mind if we had some simple way for device developers to > add migration tests that cover their code. Currently it's infeasible to > edit migration-test with new command lines for every device of > interest. Maybe we could have a little framework that takes a command > line and spits a migration stream? Something really self-contained, > behind the device's CONFIG in meson. I added one more todo: https://wiki.qemu.org/ToDo/LiveMigration#Device_migration_stream_test_framework How's that look? Feel free to modify on your will. -- Peter Xu
