On Mon, Jul 13, 2026 at 01:55:48PM +0300, Vladimir Sementsov-Ogievskiy wrote: > On 13.07.26 12:51, Daniel P. Berrangé wrote: > > On Fri, Jul 10, 2026 at 10:17:58PM +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 devices that support it (none at the moment). > > > > > > Signed-off-by: Vladimir Sementsov-Ogievskiy <[email protected]> > > > Acked-by: Markus Armbruster <[email protected]> > > > Acked-by: Peter Xu <[email protected]> > > > Reviewed-by: Ben Chaney <[email protected]> > > > --- > > > include/migration/misc.h | 2 ++ > > > migration/options.c | 18 +++++++++++++++++- > > > qapi/migration.json | 12 ++++++++++-- > > > 3 files changed, 29 insertions(+), 3 deletions(-) > > > > > > > diff --git a/qapi/migration.json b/qapi/migration.json > > > index 66bd900465a..03bdf19f3a6 100644 > > > --- a/qapi/migration.json > > > +++ b/qapi/migration.json > > > @@ -830,7 +830,8 @@ > > > 'zero-page-detection', > > > 'direct-io', > > > { 'name': 'x-rdma-chunk-size', 'features': [ 'unstable' ] }, > > > - 'cpr-exec-command'] } > > > + 'cpr-exec-command', > > > + 'local'] } > > > ## > > > # @migrate-set-parameters: > > > @@ -1012,6 +1013,12 @@ > > > # Must be set to the same value on both source and destination > > > # before migration starts. (Since 11.1) > > > # > > > +# @local: Enable local migration for devices that support it. Backend > > > +# state and its file descriptors can then be passed to the > > > +# destination in the migration channel. The migration channel > > > +# must be a Unix domain socket. Usually needs to be enabled per > > > +# device. (Since 11.2) > > > > What happens when this is enabled and there are devices which > > don't support it ? > > These devices are migrated as usual, ignoring "local" option. > > > > > What happens when this is enabled and a device on the src > > does not support it but a device on the (newer) QEMU dest > > does support it ? How does the mgmt app know which devices > > support it ? > > The only supporting device (TAP-backend) declares support by > "local-migration-supported", so mgmt app should care to set > same value for it on host and target (like for other options > actually). Or simply relay on default, which is true starting > from 11.2 Machine Type. > > > > > Can we document the semantics in these cases. > > That's: "Usually needs to be enabled per device."
....except that we have it enabled by default for TAP backends in new machine types.... except that it will then break if the app/user has enabled any of the "forbidden" options. The way this doc is written makes it sound like "local" is an optimization you can turn on in any scenario, and it will do the right thing if the device supports it. That is very much not the case - enabling this flag will definitely break many configs out of the box, with new machine types due to the TAP device defaults & incompatible options. > So, we (may) have three types of devices: > > 1. Not supporting "local" migration: they just ignore "local" migration > parameter. Yep, the easy case. > > 2. Supporting "local" from the beginning (not such devices for now): > they simply do "local" migration when "local" is set, and "usual" > migration when "local" is not set. ...except that abort the migration if you used any forbidden options. I really dislike this as default out of the box behaviour for the TAP backend. > 3. Support for "local" appears at some moment (like TAP in this series). > Such devices should have a possibility to enable/disable the "support > for local" by hand, to be able to migrate betweend supporting and > not supporting QEMU versions. If the mgmt app is manually enabling the feature, then mitigates the problem of forbidden options, as they should be aware of whether their config is safe to enable or not. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
