On 05.06.26 17:08, Peter Xu wrote:
On Fri, Jun 05, 2026 at 10:35:52AM +0300, Vladimir Sementsov-Ogievskiy wrote:
On 04.06.26 21:01, Peter Xu wrote:
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.
Yes, it doesn't work for TAP devices added through commandline. But
if devices are added only throuhg QMP (isn't libvirt do so?), it
should work.
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.
Agree, right. I missed further outgoing migration.
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.
So, possible way is:
1. net devices are only added by QMP commands
2. migration parameter "local" is set before adding devices
So, we can omit "incoming-fds" and rely on "local" && "support-local-migration".
And we can check in .pre_incoming of TAP device, does current value of "local"
equal to what it was at time of TAP initialization, and fail if it differs.
Still, having explicit incoming-fds looks safer, as it's more difficult to do
a mistake.
If this will be the only outlier, then maybe yes, an extra option in a
special device backend isn't much of an issue.
The question is if there'll be more things relying on "local=on". We may
not want to keep introducing per-device flags even if all of them can play
the same role as migration's "local".
Agree.
Hmm, so, may be, I just go this way for my series? It will just work with
these two restrictions above, which is OK for me. And no conflict with
new "-incoming" design.
--
Best regards,
Vladimir
