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. 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". > > 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 -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
