On 10.03.26 16:46, Markus Armbruster wrote:
Vladimir Sementsov-Ogievskiy <[email protected]> writes:
Support transferring of TAP state (including open fd) through
migration stream as part of viritio-net "local-migration".
Add new option, incoming-fds, which should be set to true to
trigger new logic.
For new option require explicitly unset script and downscript,
to keep possibility of implementing support for them in future.
Signed-off-by: Vladimir Sementsov-Ogievskiy <[email protected]>
[...]
diff --git a/qapi/net.json b/qapi/net.json
index 118bd349651..79f5ce9f431 100644
--- a/qapi/net.json
+++ b/qapi/net.json
@@ -355,6 +355,9 @@
# @poll-us: maximum number of microseconds that could be spent on busy
# polling for tap (since 2.7)
#
+# @incoming-fds: do not open/connnect any resources, instead wait for
+# TAP state from incoming migration stream. (Since 11.0)
"resources"? The name @incoming-fds suggests this is about file
descriptors...
Hmm. But, I can't say "open any file descriptors"..
"wait for TAP state from" does not make sense. Do you mean "retrieve
TAP state from"?
Retrieve means actively do something, but I mean, that FDs will come in
future from incoming migration stream, and we just wait for it and "do nothing"
at the moment of net-tap initialization.
Let me try to reword:
Do not open or create any TAP devices. Prepare for getting opened
TAP file descriptors from incoming migration stream.
Is any part of NetdevTapOptions ignored when @incoming-fds is true?
Hmm yes. sndbuf, vnet_hdr and ifname. I should add this information here.
+#
# Since: 1.2
##
{ 'struct': 'NetdevTapOptions',
@@ -373,7 +376,8 @@
'*vhostfds': 'str',
'*vhostforce': 'bool',
'*queues': 'uint32',
- '*poll-us': 'uint32'} }
+ '*poll-us': 'uint32',
+ '*incoming-fds': 'bool' } }
##
# @NetdevSocketOptions:
--
Best regards,
Vladimir
