On 15.10.25 21:27, Peter Xu wrote:
Interesting, could migration "return path" be somehow used to get information
from target, does it support backend transfer for concrete device?
So that, we simply enable backend-transfer=true parameter both on
source and target. Than, source somehow find out through return path,
for the device, does target support backend-transfer for it, and decide,
what to do? Or that's too complicated?
Fabiano is looking at something like that, we called it migration
handshake.
https://wiki.qemu.org/ToDo/LiveMigration#Migration_handshake
Fundamentally one of its goal is that we can have bi-directional "talks"
between src/dst, before migration ever started, to synchronize on things
like this. It's still likely not gonna happen this release.. though.. but
it's on the radar. With that, dst also doesn't need to set migration
caps/params the same as src, because they'll talk things over.
Oh, that sounds cool, I've always dreamed of something like this.
Note for myself: look through the QEMU wiki, it may contain quite interesting
things,
not only "QEMU Planning" and "Submit a Patch" :)
For live-update with backend transfer, we'll probably can not only check the
device tree, but recreate it automatically, using information from target.
Allow QMP command "migrate[_incoming]" ..
O I thought about this too.
-
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.
--
Best regards,
Vladimir
