Re: [PATCH RFC 0/2] migration/vl: new -incoming config:* for early migration parameters

[Peter Xu <peterx@redhat.com>]

On Thu, Jun 04, 2026 at 01:00:10AM +0300, Vladimir Sementsov-Ogievskiy wrote:
> On 03.06.26 21:46, Peter Xu wrote:
> > > My general feeling wrt changes to the current command line is that
> > > any suggestion should be desgined with a nod towards a future scenario
> > > where QEMU is 100% configured with QMP. ie the full command line is
> > > 
> > >     qemu-system-x86_64 -qmp <address>
> > > 
> 
> [..]
> 
> > 
> > Requirements like this (allow migration parameters to be accessible during
> > early stage of QEMU) is going towards the other direction of the that idea.
> > That means even if we put all configs (caps/params) into QMP command
> > migrate[-incoming], libvirt will still need to manage these global setup
> > and making sure when invoking migrate[-incoming] QMP commands they match
> > with the globals.  Say, if one start QEMU with -incomingconfig:local=on
> > but then invoke "migrate-incoming,local=off" it's illegal.
> 
> Right.. And this show, that moving "local" from migrate-set-parameters to
> commandline is not a clear solution for the whole problem.
> 
> We don't need cmdline argument. We need two things:
> 
> 1. "local" must be set before initializing tap-device.
> 
> It not actually requires it being a cmdline parameter. Calling
> migrate-set-parameters before netdev_add is also OK.

Ohh is it ok?  I thought it was not OK so we look at this.

Say, this is what I see on init TAP device when without hotplug:

qemu_create_late_backends() -> net_init_clients()

Such happens before migration object initialization.

> 
> So, moving to cmdline solves this [1] point, but may be too restrictive.
> 
> 
> 2. "local" must not be changed after initializing tap-device.
> 
> And this one is not guaranteed anyway, with cmdline or with QMP.
> 
> ---
> 
> 
> So, in my series, if drop "incoming-fds" and rely on "local" instead, we
> actually want "local" be immutable after first read in tap initialization
> code.
> 
> Maybe, just implement this feature? So, in code it will look like:
> 
> set_migration_parameters(...) {
> 
> ...
> 
> if "local" value is changing and "local" is immutable:
>    fail

We can't do that, can we?

Imagine we need to further migrate this VM to another host, where we need
to turn "local" off after this incoming migration.. we can forbid only
during incoming phase and re-enable the mutability, but it seems too much.

My understanding is such protection is fine but not strongly necessary.
IMHO we rely on a lot of things that admin needs to do right.  I hope this
isn't a major issue to offload that to admin to say the admin should always
do the right things.

We have a bunch of similar issues in QEMU IIUC, e.g. we have known issue
that some -device needs to be ordered in some way otherwise it'll stop
working.  We then need admin (or in this case libvirt) do the right thing
too.

> 
> ...
> 
> }
> 
> 
> tap_initializaion(...) {
> 
> ...
> 
> local = migrate_get_local_and_make_it_immutable(err_text="you can not change 'local' parameter value after TAP device initialization");
> 
> ...
> 
> 
> }
> 
> ---
> 
> For user it should provide simple error messages
> 
>    "you can not change 'local' parameter value after TAP device initialization".
> 
> if user tries to change local when it's not allowed.
> 
> 
> -- 
> Best regards,
> Vladimir
> 

-- 
Peter Xu