On 13.07.26 23:22, Michael S. Tsirkin wrote:
On Mon, Jul 13, 2026 at 07:37:50PM +0100, Daniel P. Berrangé wrote:
On Mon, Jul 13, 2026 at 08:55:37PM +0300, Vladimir Sementsov-Ogievskiy wrote:
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.
How about....
# @local: Permit the use of optimizations for local migration.
# This must only be set when both the source and destination
# QEMU processes are on the same OS and directly connected
# with a UNIX domain socket as the migration channel to enable
# use of file descriptor passing. Individual device backends
# may need additional configuration flags set to enable local
# migration optimizations. This will be documented against the
# device backends where it applies. (Since 11.2)
BTW surely qemu can just detect this? getsockname maybe?
Yes, but this doesn't guarantee that it's a direct connection by UNIX
socket to target, and it really can pass FDs. UNIX socket may be only
a first part of transfer channel to the remote target.
--
Best regards,
Vladimir
