On 13.07.26 14:21, Daniel P. Berrangé wrote:
On Mon, Jul 13, 2026 at 01:55:48PM +0300, Vladimir Sementsov-Ogievskiy wrote:
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."
....except that we have it enabled by default for TAP backends
in new machine types.... except that it will then break if the
app/user has enabled any of the "forbidden" options.
The way this doc is written makes it sound like "local" is an
optimization you can turn on in any scenario, and it will do
the right thing if the device supports it. That is very much
not the case - enabling this flag will definitely break many
configs out of the box, with new machine types due to the TAP
device defaults & incompatible options.
Ok, now we decided to NOT make default support for TAP in newer
machine types.
So, enabling "local" is safe in existing scenarios, only explicit
enabling TAP.local-migration-supported will change the behavior.
Keep "local" documentation as is?
I see the only way to make it more informative: directly describe
connection with TAP.local-migration-supported, without general
phrases about "devices that support" and "usual". We'll have to
update it when more devices added (my next step is vhost-user-blk),
but at least, it would be absolutely correct at the moment.
So, we (may) have three types of devices:
1. Not supporting "local" migration: they just ignore "local" migration
parameter.
Yep, the easy case.
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.
...except that abort the migration if you used any forbidden options.
I really dislike this as default out of the box behaviour for the
TAP backend.
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.
If the mgmt app is manually enabling the feature, then mitigates
the problem of forbidden options, as they should be aware of
whether their config is safe to enable or not.
With regards,
Daniel
--
Best regards,
Vladimir
