On 16.10.25 19:25, Peter Xu wrote:
On Wed, Oct 15, 2025 at 11:17:27PM +0300, Vladimir Sementsov-Ogievskiy wrote:
Off topic:
Didn't you think about moving to some context-free protocol for migration
stream? Current protocol is hardly bound to migration states definitions
in the code. This, for example, makes writing an external tool to analyze the
stream almost impossible. As well, any misconfiguration leads to strange
error, when we treat data wrongly on the target.
I imagine.. json? Or something like this.. So that we can always understand
the structure of incoming object, even if we don't know, what exactly we
are going to get. This also simplifies expanding the state in new verions:
we just add a new field into migratable object, and can handle absent field
in incoming stream.
Have you looked at the current encoded JSON dump within the migration
stream? See should_send_vmdesc().
That looks like what you're describing, but definitely different in that it
should only be used for debugging purposes e.g. when a stream is dumped
into a file. The JSON should only only appear also on precopy as of now.
We might try to move it _before_ the real binary stream, or making the
stream itself to be JSON, but there'll be tricky things we need to think
about.
At least it should be problematic when we want to dump it before the binary
stream, because there can be VMSD fields or subsections that has a test()
function that will only conditionally appear depending on any possible
conditions (e.g. device register states). If we try to dump it before
hand, it may mean after device registers changed and when we stop VM and
dump the real binary stream the test() fn may return something different,
starting to mismatch with the JSON description.
Dump the whole thing completely with JSON format is indeed another approach
Yes I meant this. Or maybe some other external binary protocol like protobuf.
that I am not aware of anyone hought further. I believe some of us
(including myself) pictured how it could look like, but I am not aware
anyone went deeper than that. Maybe it's because the current methods work
not as good but okay so that no one yet decided to think it all through.
In short, for simple machine types, they use VMSD versioning hence backward
migration is not supported. For enterprise use, machine type properties
are used and there aren't a huge lot so maybe not as bothering.
yes. Too much work with little benefit..
another thought:
We have QAPI protocol, with quite good schema description, and we can add
new optional fields to structures, and backward compatibility works.
Maybe, we can migrate a QAPI generated structures? Then we may describe
state of devices in QAPI..
Just note: working with QEMU's migration protocol and QAPI for years,
I can say that QAPI is a lot simpler in:
- implementing new features in backward compatible style
- maintaining downstream-only features
Still, QAPI is not good for passing big chunks of raw data, like memory pages.
--
Best regards,
Vladimir
