From: Markus Armbruster <armbru@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Cc: jasowang@redhat.com, mst@redhat.com, peterx@redhat.com,
farosas@suse.de, raphael.s.norwitz@gmail.com,
bchaney@akamai.com, qemu-devel@nongnu.org, berrange@redhat.com,
pbonzini@redhat.com, yc-core@yandex-team.ru,
mark.caveayland@nutanix.com, Jason Wang <jasowangio@gmail.com>,
Eric Blake <eblake@redhat.com>
Subject: Re: [PATCH v21 15/16] net/tap: support local migration with virtio-net
Date: Thu, 20 Aug 2026 11:16:45 +0200 [thread overview]
Message-ID: <87cxvd2ltu.fsf@pond.sub.org> (raw)
In-Reply-To: <20260819180201.1970193-16-vsementsov@yandex-team.ru> (Vladimir Sementsov-Ogievskiy's message of "Wed, 19 Aug 2026 21:01:58 +0300")
Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> writes:
> Support transferring of TAP state (including open fd).
>
> Add new property "x-permit-local-migration", which defines whether
> local migration is actually permitted for this TAP device.
>
> Note that local-migration is enabled by global "local" migration
> parameter, but individual devices may have additional options to
> enable/disable it per device.
>
> The tricky thing is that we need to know whether to call open/connect in
> TAP initialization code, i.e. we need to know the value of migration
> parameter "local" when creating the TAP device. For incoming migration,
> we can know only for TAP devices created with QMP after setting the
> migration parameter with QMP.
>
> So the full picture is:
>
> On source, to start outgoing "local" migration you need:
>
> - migration parameter "local" set to true
> - "x-permit-local-migration" TAP option set to true
>
> If at least one of these options is not set, TAP backend
> doesn't participate in migration.
>
> On target, things are more difficult:
>
> Same, you need both "local" and "x-permit-local-migration"
> be set. And same, if one of them is not set, TAP backend
> is initialized as usual, and doesn't accept any incoming
> state.
>
> Additionally, if you are going to set "local", it must be
> set before creating the TAP device. If TAP device created
> with "local" unset, it initializes as usual. If you enable
> "local" after it and start incoming migration, it will fail
> in .pre_load handler of TAP backend.
>
> Moreover, there are interface restrictions: if you create TAP
> device when QEMU is in INCOMING state, and both "local"
> and "x-permit-local-migration" set, most of TAP options are
> not allowed, and script/downscript are required to be explicitly
> disabled.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
> Reviewed-by: Ben Chaney <bchaney@akamai.com>
QAPI schema
Acked-by: Markus Armbruster <armbru@redhat.com>
next prev parent reply other threads:[~2026-08-20 9:17 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260819180201.1970193-1-vsementsov@yandex-team.ru>
2026-08-19 18:01 ` [PATCH v21 01/16] net/tap: rework tap_parse_script Vladimir Sementsov-Ogievskiy
2026-08-19 18:01 ` [PATCH v21 02/16] net/tap: improve script/downscript options documentation Vladimir Sementsov-Ogievskiy
2026-08-19 18:01 ` [PATCH v21 03/16] net/tap: deprecate "no" as special value for script/downscript Vladimir Sementsov-Ogievskiy
2026-08-19 18:01 ` [PATCH v21 05/16] net/tap: move vhost initialization to tap_setup_vhost() Vladimir Sementsov-Ogievskiy
2026-08-19 18:01 ` [PATCH v21 06/16] net/tap: use container_of instead of DO_UPCAST Vladimir Sementsov-Ogievskiy
2026-08-19 18:01 ` [PATCH v21 07/16] net/tap: QOMify tap backend Vladimir Sementsov-Ogievskiy
2026-08-19 18:01 ` [PATCH v21 10/16] migration/fd: fix fd leak when fd is not valid for migration Vladimir Sementsov-Ogievskiy
2026-08-19 18:53 ` Peter Xu
2026-08-19 18:01 ` [PATCH v21 11/16] migration/fd: add errp parameter to migration_fd_valid() Vladimir Sementsov-Ogievskiy
2026-08-19 18:54 ` Peter Xu
2026-08-19 18:01 ` [PATCH v21 12/16] migration: check that transfer is UNIX socket when "local" set Vladimir Sementsov-Ogievskiy
2026-08-19 18:59 ` Peter Xu
2026-08-19 18:01 ` [PATCH v21 13/16] virtio-net: support local migration of backend Vladimir Sementsov-Ogievskiy
2026-08-19 18:01 ` [PATCH v21 15/16] net/tap: support local migration with virtio-net Vladimir Sementsov-Ogievskiy
2026-08-20 9:16 ` Markus Armbruster [this message]
2026-08-19 18:01 ` [PATCH v21 16/16] tests/functional: add test_tap_migration Vladimir Sementsov-Ogievskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87cxvd2ltu.fsf@pond.sub.org \
--to=armbru@redhat.com \
--cc=bchaney@akamai.com \
--cc=berrange@redhat.com \
--cc=eblake@redhat.com \
--cc=farosas@suse.de \
--cc=jasowang@redhat.com \
--cc=jasowangio@gmail.com \
--cc=mark.caveayland@nutanix.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=raphael.s.norwitz@gmail.com \
--cc=vsementsov@yandex-team.ru \
--cc=yc-core@yandex-team.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox