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...
"wait for TAP state from" does not make sense. Do you mean "retrieve
TAP state from"?
Is any part of NetdevTapOptions ignored when @incoming-fds is true?
> +#
> # 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:
