On Fri, Feb 20, 2026 at 10:56:50AM +0300, Vladimir Sementsov-Ogievskiy wrote: > On 20.02.26 00:43, Peter Xu wrote: > > On Thu, Feb 19, 2026 at 02:55:24PM +0300, Vladimir Sementsov-Ogievskiy > > wrote: > > > We are going to implement local-migration feature: some devices will be > > > able to transfer open file descriptors through migration stream (which > > > must UNIX domain socket for that purpose). This allows to transfer the > > > whole backend state without reconnecting and restarting the backend > > > service. For example, virtio-net will migrate its attached TAP netdev, > > > together with its connected file descriptors. > > > > > > In this commit we introduce a migration parameter, which enables > > > the feature for supporting devices (no one at the moment). > > > > > > Signed-off-by: Vladimir Sementsov-Ogievskiy <[email protected]> > > > > Reviewed-by: Peter Xu <[email protected]> > > > > PS: one nitpick is maybe we don't need to spell out the per-device option > > in the doc of "local", it also doesn't need to be called "local-migration" > > on every device if it will be presnet.. no strong feelings. > > > > I thought about it.. But couldn't come up with a more generic phrase. > And I think it's bad to omit the fact that the parameter doesn't > automatically enable the feature without some flag on device side. > > +# channel. Individual devices declare the support for local > +# migration by per-device local-migration option. (Since 11.0) > > Hmm. After merging at least virtio-net/TAP migration we can write: > > In general devices may have an option (like local-migration > for virtio-net) which in conjunction with "local" set to true > enables the local-migration feature for that device. > > And to be prepared for it now: > > In general devices may have an option which in conjunction with > "local" set to true enables the local-migration feature for that > device.
Yep, this looks good. The per-device option is not required IMHO, so "may have" is accurate to me. For example, when we introduce a completely new device, it can support migrate_is_local() since the first day, then it doesn't need the per device knob. OTOH, the global "local" parameter is needed only because we want a promise from the user that this is a local migration, instead of relying on URI being unix sockets. One example is in kubevirt AFAIU we use unix sockets even for remote migrations (where the unix socket will only be used as a proxy to route things outside of the container). Hence "local" deduces "unix sockets", not vice versa. Thanks, -- Peter Xu
