On 14.07.26 22:24, Michael S. Tsirkin wrote:
On Tue, Jul 14, 2026 at 09:43:52AM +0300, Vladimir Sementsov-Ogievskiy wrote:
On 13.07.26 22:36, Michael S. Tsirkin wrote:
On Fri, Jul 10, 2026 at 10:18:01PM +0300, Vladimir Sementsov-Ogievskiy wrote:
Support transferring of TAP state (including open fd).
Add new property "local-migration-supported", which defines
whether local-migration is actually supported for this TAP device.
Starting from 11.2 QEMU Machine Types it's enabled by default.
Note, that local-migration (including migrating opened FDs
through migration channel, which must be UNIX socket), is
enabled by global "local" migration parameters. But individual
devices may have additional options to enable/disable it
per device.
The tricky thing, is that we need to know, should we do
call open/connect in TAP initialization code. That means,
that on incoming migration we want to know status of
"local" migration parameter at time of creating TAP device.
So, currently, for incoming local migration only TAP device
created through QMP is supported, as you need to set migration
parameter first (through QMP as well).
So the full picture is:
On source, to start outgoing "local" migration you need:
- migration parameter "local" set to true
- "local-migration-supported" TAP option set to true (the
default, starting from 11.2 QEMU Machine Types)
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 "local-migration-supported"
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 "local-migration-supported" set, most of TAP options are
not allowed, and script/downscript are required to be explicitly
unset (set to "" or "no").
Signed-off-by: Vladimir Sementsov-Ogievskiy<[email protected]>
I am still confused why is this per device. I just do not
see where is it useful to set it for some devices
but not others. So it looks like a machine property
"incoming local migration" to me?
Sorry if I am being dense.
1. We need at least "per device class": when local-migration-support is
implemented for some new device, we still need to migrate from/to older
version without this support.
Assume we have "local" migration parameter and support for TAP in 11.2.
Then, in 12.0 support for vhost-user-blk is implemented. If we have only
global "local" parameter, the migration will be broken between 11.2 and
12.0,
with local=true, as in 11.2 it means only TAP local migration, but
in 12.0 it means both TAP and vhost-user-blk local migration.
Of course, now it's a bit redundant, as we have only TAP, and may define,
that TAP is always supported (as support is introduced together with
"local"). But there are another considerations:
If this is your way to version the behaviour, that is fine, but it should
be an internal property without ABI guarantees, starting with "x-".
2. Symmetry: if have a possiblity to disable feature only for vhost-user-blk,
seems good to have same possibility for TAP.
3. Disabling fd-migration per device may be useful to switch this specific
device to another backend.
Unclear what good is it, and the drawback is that it blows up the size
of our testing/support matrix.
OK. If you are ok with unstable property x-local-migration-supported, I'm
happy with it as well. I'll post a squash-in for already sent v19 [13/15] patch.
(To be honest, I'm OK with _any_ API, and this whole (almost a year!) story
is trying to satisfy all the maintainers at the same time o_O)
--
Best regards,
Vladimir
