On 13.07.26 12:51, Daniel P. Berrangé wrote:
On Fri, Jul 10, 2026 at 10:17:58PM +0300, Vladimir Sementsov-Ogievskiy wrote:
We are going to implement local-migration feature: some devices will be
able to transfer open file descriptors through migration stream (which
must UNIX domain socket for that purpose). This allows to transfer the
whole backend state without reconnecting and restarting the backend
service. For example, virtio-net will migrate its attached TAP netdev,
together with its connected file descriptors.
In this commit we introduce a migration parameter, which enables
the feature for devices that support it (none at the moment).
Signed-off-by: Vladimir Sementsov-Ogievskiy <[email protected]>
Acked-by: Markus Armbruster <[email protected]>
Acked-by: Peter Xu <[email protected]>
Reviewed-by: Ben Chaney <[email protected]>
---
include/migration/misc.h | 2 ++
migration/options.c | 18 +++++++++++++++++-
qapi/migration.json | 12 ++++++++++--
3 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/qapi/migration.json b/qapi/migration.json
index 66bd900465a..03bdf19f3a6 100644
--- a/qapi/migration.json
+++ b/qapi/migration.json
@@ -830,7 +830,8 @@
'zero-page-detection',
'direct-io',
{ 'name': 'x-rdma-chunk-size', 'features': [ 'unstable' ] },
- 'cpr-exec-command'] }
+ 'cpr-exec-command',
+ 'local'] }
##
# @migrate-set-parameters:
@@ -1012,6 +1013,12 @@
# Must be set to the same value on both source and destination
# before migration starts. (Since 11.1)
#
+# @local: Enable local migration for devices that support it. Backend
+# state and its file descriptors can then be passed to the
+# destination in the migration channel. The migration channel
+# must be a Unix domain socket. Usually needs to be enabled per
+# device. (Since 11.2)
What happens when this is enabled and there are devices which
don't support it ?
These devices are migrated as usual, ignoring "local" option.
What happens when this is enabled and a device on the src
does not support it but a device on the (newer) QEMU dest
does support it ? How does the mgmt app know which devices
support it ?
The only supporting device (TAP-backend) declares support by
"local-migration-supported", so mgmt app should care to set
same value for it on host and target (like for other options
actually). Or simply relay on default, which is true starting
from 11.2 Machine Type.
Can we document the semantics in these cases.
That's: "Usually needs to be enabled per device."
Requiring any device to have a specific options like
"local-migration-supported" (for TAP device in this series) would
be not correct if new devices added, supporting "local" migration
from the beginning..
So, we (may) have three types of devices:
1. Not supporting "local" migration: they just ignore "local" migration
parameter.
2. Supporting "local" from the beginning (not such devices for now):
they simply do "local" migration when "local" is set, and "usual"
migration when "local" is not set.
3. Support for "local" appears at some moment (like TAP in this series).
Such devices should have a possibility to enable/disable the "support
for local" by hand, to be able to migrate betweend supporting and
not supporting QEMU versions.
Unsure, that we need this all be described here, may be, just ref
the only supporting device (TAP), so user may go to
"local-migration-supported" description for details?
+#
# Features:
#
# @unstable: Members @x-checkpoint-delay, @x-rdma-chunk-size, and
@@ -1053,7 +1060,8 @@
'*direct-io': 'bool',
'*x-rdma-chunk-size': { 'type': 'uint64',
'features': [ 'unstable' ] },
- '*cpr-exec-command': [ 'str' ]} }
+ '*cpr-exec-command': [ 'str' ],
+ '*local': 'bool' } }
##
# @query-migrate-parameters:
--
2.43.0
With regards,
Daniel
--
Best regards,
Vladimir
