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?
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..
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
--
Best regards,
Vladimir
