On 16.10.25 23:26, Vladimir Sementsov-Ogievskiy wrote:
On 16.10.25 12:23, Vladimir Sementsov-Ogievskiy wrote:
On 16.10.25 11:32, Daniel P. Berrangé wrote:
On Thu, Oct 16, 2025 at 12:02:45AM +0300, Vladimir Sementsov-Ogievskiy wrote:
On 15.10.25 23:07, Peter Xu wrote:
[..]
3. Local migration, but we want to reconfigure some backend, or switch
to another backend. We disable "backend-transfer" for one device.
This implies that you're changing 'backend-transfer' against the
device at time of each migration.
This takes us back to the situation we've had historically where the
behaviour of migration depends on global properties the mgmt app has
set prior to the 'migrate' command being run. We've just tried to get
away from that model by passing everything as parameters to the
migrate command, so I'm loathe to see us invent a new way to have
global state properties changing migration behaviour.
This 'backend-transfer' device property is not really a device property,
it is an indirect parameter to the 'migrate' command.
Ergo, if we need the ability to selectively migrate the backend state
of individal devices, then instead of a property on the device, we
should pass a list of device IDs as a parameter to the migrate
command in QMP.
Understand.
So, it will look like
# @backend-transfer: List of devices IDs or QOM paths, to enable
# backend-transfer for. In general that means that backend
# states and their file descriptors are passed to the destination
# in the migration channel (which must be a UNIX socket), and
# management tool doesn't have to configure new backends for
# target QEMU (like vhost-user server, or TAP device in the kernel).
# Default is no backend-transfer migration (Since 10.2)
RFC diff to these series, to switch the API to list of IDs:
[..]
@@ -1193,6 +1198,11 @@ bool migrate_params_check(MigrationParameters *params,
Error **errp)
return false;
}
+ if (params->has_backend_transfer &&
+ !migrate_backend_transfer_check_list(params->backend_transfer, errp)) {
+ return false;
+ }
This made me to move capabilities setup after device add in the test. Not a
problem.
+
return true;
}
[..]
- vm.cmd("migrate-set-parameters", {
- "backend-transfer": backend_transfer
- })
+ ]
+ vm.cmd("migrate-set-capabilities", {"capabilities": capabilities})
+ if backend_transfer:
+ vm.cmd(
+ "migrate-set-parameters",
+ {"backend-transfer":
["/machine/peripheral/vnet.1/virtio-backend"]},
If write just "vnet.1" it doesn't work, of course. Is there some way get
pointer to
proxy device from virtio-net.c? But maybe, it's OK as is.
+ )
def setup_guest_network(self) -> None:
exec_command_and_wait_for_pattern(self, "ip addr", "# ")
--
Best regards,
Vladimir
