On Fri, Sep 05, 2025 at 04:50:34PM +0300, Vladimir Sementsov-Ogievskiy wrote: > diff --git a/qapi/migration.json b/qapi/migration.json > index 2387c21e9c..992a5b1e2b 100644 > --- a/qapi/migration.json > +++ b/qapi/migration.json > @@ -517,6 +517,12 @@ > # each RAM page. Requires a migration URI that supports seeking, > # such as a file. (since 9.0) > # > +# @local-tap: Migrate TAPs locally, keeping backend alive. Open file > +# descriptors and TAP-related state are migrated. Only may be > +# used when migration channel is unix socket. For target device > +# also @local-incoming option must be specified (since 10.2) > +# (since 10.2)
IMHO we should move this into a per-device property, at least we need one there to still control the device behavior; we had a similar discussion recently on iterable virtio-net. But maybe this one is slightly special? Maybe the tap device needs to at least know whether in this specific migration, if we want to pass over FD or not (e.g. local upgrade, or remote _real_ migration)? If that's the case, we may consider providing a generic migration capability, like cap-fd-passing. Nowadays since Fabiano's moving migration capabilities all over to migration parameters, this one can start with a parameter instead of a capability. The problem with migration capability is (at least) that it can't by default ON on any machine types.. meanwhile it simply looks like identital to parameters except it's always bool. The high level rational is that we should never add a per-device cap flag into migration framework. Thanks, -- Peter Xu
