On 12.09.25 17:56, Markus Armbruster wrote:
Vladimir Sementsov-Ogievskiy <vsement...@yandex-team.ru> writes:
This commit introduces a possibility to migrate open chardev
socket fd through migration channel without reconnecting.
For this, user should:
- enable new migration capability local-char-socket
- mark the socket by an option support-local-migration=true
- on target add local-incoming=true option to the socket
Motivation for the API:
1. We don't want to migrate all sockets. For example, QMP-connection is
bad candidate, as it is separate on source and target. So, we need
@support-local-migration option to mark sockets, which we want to
migrate (after this series, we'll want to migrate chardev used to
connect with vhost-user-server).
2. Still, for remote migration, we can't migrate any sockets, so, we
need a capability, to enable/disable the whole feature.
3. And finally, we need a sign for the socket to not open a connection
on initialization, but wait for incoming migration. We can't use
@support-local-migration option for it, as it may be enabled, but we
are in incoming-remote migration. Also, we can't rely on the
migration capability, as user is free to setup capabilities before or
after chardev creation, and it would be a bad precedent to create
relations here.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsement...@yandex-team.ru>
[...]
diff --git a/qapi/char.json b/qapi/char.json
index f0a53f742c..5b535c196a 100644
--- a/qapi/char.json
+++ b/qapi/char.json
@@ -280,11 +280,23 @@
# mutually exclusive with @reconnect.
# (default: 0) (Since: 9.2)
#
+# @support-local-migration: The socket open file descriptor will
+# migrate if this field is true and local-char-socket migration
+# capability enabled (default: false) (Since: 10.2)
+#
+# @local-incoming: Do load open file descriptor for the socket
+# on incoming migration. May be used only if QEMU is started
+# for incoming migration and only together with local-char-socket
+# migration capability (default: false) (Since: 10.2)
+#
# Features:
#
# @deprecated: Member @reconnect is deprecated. Use @reconnect-ms
# instead.
#
+# @unstable: Members @support-local-migration and @local-incoming
+# are experimental
+#
# Since: 1.4
##
{ 'struct': 'ChardevSocket',
@@ -298,7 +310,9 @@
'*tn3270': 'bool',
'*websocket': 'bool',
'*reconnect': { 'type': 'int', 'features': [ 'deprecated' ] },
- '*reconnect-ms': 'int' },
+ '*reconnect-ms': 'int',
+ '*support-local-migration': { 'type': 'bool', 'features': [
'unstable' ] },
+ '*local-incoming': { 'type': 'bool', 'features': [ 'unstable' ] }
},
'base': 'ChardevCommon' }
##
diff --git a/qapi/migration.json b/qapi/migration.json
index 2387c21e9c..4f282d168e 100644
--- a/qapi/migration.json
+++ b/qapi/migration.json
@@ -517,6 +517,11 @@
# each RAM page. Requires a migration URI that supports seeking,
# such as a file. (since 9.0)
#
+# @local-char-socket: Migrate socket chardevs open file descriptors.
+# Only may be used when migration channel is unix socket. Only
+# involves socket chardevs with "support-local-migration" option
+# enabled. (since 10.2)
+#
# Features:
#
# @unstable: Members @x-colo and @x-ignore-shared are experimental.
@@ -536,7 +541,8 @@
{ 'name': 'x-ignore-shared', 'features': [ 'unstable' ] },
'validate-uuid', 'background-snapshot',
'zero-copy-send', 'postcopy-preempt', 'switchover-ack',
- 'dirty-limit', 'mapped-ram'] }
+ 'dirty-limit', 'mapped-ram',
+ { 'name': 'local-char-socket', 'features': [ 'unstable' ] } ] }
##
# @MigrationCapabilityStatus:
I understand why we need a knob to enable the feature. A
MigrationCapability looks fine to me. We could perhaps come up with a
better name, but let's leave that for later.
I'm unsure about making users mark the sockets (really: the sockets
wrapped in a character device backend) to be migrated that way.
Which sockets are users supposed to mark, and how would they know?
What happens when a user marks the QMP socket? You called that a "bad
candidate".
Doesn't feel like good user interface design.
Could QEMU decide (in principle) which sockets are suitable for
sending down the migration channel?
If yes, could we make it do the right thing automatically? Or at least
a check that stops the user from doing the wrong thing?
Yes, I'm thinking about this too. In my live-TAP series, I don't migrate TAP
netdev in separate, but it's migrated as part of virtio-net device. I hope,
it should be possible to do something similar here.
So the good target interface for me now is one "migarate-fds" (or better named)
capability, which turns on the whole feature both for virtio-net and
vhost-user-blk
devices (and probably future ones). With additional optional device parameters
to be able to disable fds-migration per-device.
--
Best regards,
Vladimir
