On 17.10.25 11:50, Daniel P. Berrangé wrote:
On Fri, Oct 17, 2025 at 11:26:59AM +0300, Vladimir Sementsov-Ogievskiy wrote:
On 17.10.25 11:10, Daniel P. Berrangé wrote:
Meanwhile, the admin will need to manage the list of devices even if the
admin doesn't really needed to, IMHO.
We shouldn't need to list devices in every scenario.
Do you mean, we may make union,
backend-transfer = true | false | [list of IDs]
Where true means, enable backend-transfer for all supporting devices?
So that normally, we'll not list all devices, but just set it to true?
Well I was thinking separate parameters
backend-transfer: bool
backend-transfer-devices: [str] (optional list of IDs)
but it amounts to the same thing
But this way, migration will fail, if target version doesn't support
backend-transfer for some of used devices, or support for some
another, where source lack the support. So that's a way to create a
situation, where two QEMUs, with same device options, same machine
types, same configurations and same migration parameters / capabilities
define incompatible migration states..
It is worse - the backend on both sides may support transfer,
but may none the less be incompatible due to changed configuration,
so this needs mgmt app input too.
The challenge we have is that whether or not a backend supports
transfer requires fairly detailed know of QEMU and the specific
configuration of the backend. It is pretty undesirable for mgmt
apps to have to that knowledge, as the matrix of possibilities
is quite large and liable to change over time.
If we consider 'backend transfer' to be a performance optimization,
then really we want QEMU to "do the right thing" as much as is
possible.
Source and dst QEMUs don't have a bi-directional channel though,
so they can't negotiate the common subset of backends they both
support - it'll need help from the mgmt app.
As I heard from Peter, there a future plans to create such channel
https://wiki.qemu.org/ToDo/LiveMigration#Migration_handshake
One possibility is a new QMP command "query-migratable-backends"
which lists all device IDs, whose current backend configuration
is reporting the ability to transfer state. The mgmt app could
run that on both sides of the migration, take the intersection
of the two lists, and then further subtract any devices where
it has delibrately changed the backend configuration on the dst.
If we had that, then we could always pass the ID list to the
migrate command, while also avoiding hardcoding knowledge of
QEMU backend impl details - it would largely "just work".
Yes "query + get intersection + set the list" works good for me.
That's enough abstract, the management app should not even care
what these IDs are.
And if migration-handshake realized, that (as many other
paraameters) may be simplified. We may finally have
backend-transfer = "off" | "auto" | [list of IDs]
, where "auto" means exactly negotiate with target the maximal set
of devices, for which we can do backend-transfer.
We need to focus on
the internal API design. We need to have suitable APIs exposed by backends
to allow us to query migratability and process vmstate a mere property
'backend-transfer' is insufficient, whether set by QEMU code, or set by
the mgmt app.
If we have proper APIs each device should be able to query whether its
backend can be transferred, and so "do the right thing" if backend
transfer is requested by migration. The ability to list devices in the
migrate command is only needed to be able to exclude some backends if
the purpose of migration is to change a backend
With regards,
Daniel
--
Best regards,
Vladimir
