Re: [PATCH v18 09/14] qapi: add local migration parameter

["Daniel P. Berrangé" <berrange@redhat.com>]

On Mon, Jul 13, 2026 at 08:55:37PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> On 13.07.26 14:21, Daniel P. Berrangé wrote:
> > 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 <vsementsov@yandex-team.ru>
> > > > > Acked-by: Markus Armbruster <armbru@redhat.com>
> > > > > Acked-by: Peter Xu <peterx@redhat.com>
> > > > > Reviewed-by: Ben Chaney <bchaney@akamai.com>
> > > > > ---
> > > > >    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.
> 
> Ok, now we decided to NOT make default support for TAP in newer
> machine types.
> 
> So, enabling "local" is safe in existing scenarios, only explicit
> enabling TAP.local-migration-supported will change the behavior.
> 
> Keep "local" documentation as is?
> 
> I see the only way to make it more informative: directly describe
> connection with TAP.local-migration-supported, without general
> phrases about "devices that support" and "usual". We'll have to
> update it when more devices added (my next step is vhost-user-blk),
> but at least, it would be absolutely correct at the moment.

How about....

 # @local: Permit the use of optimizations for local migration.
 #     This must only be set when both the source and destination
 #     QEMU processes are on the same OS and directly connected
 #     with a UNIX domain socket as the migration channel to enable
 #     use of file descriptor passing. Individual device backends
 #     may need additional configuration flags set  to enable local
 #     migration optimizations. This will be documented against the
 #     device backends where it applies. (Since 11.2)


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 :|