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.
With incoming-fds=true, user is sure, that new target vm will not try
to connect/open resources, which are still used by running source vm,
regardless of migration configuration correctness.
For example, if user accidentally set "local" _after_ creating TAP device,
we can of-course check it in .pre_incoming and fail, but at the moment we
already break networking in running guest, by attaching to same backend on
target QEMU.
--
Best regards,
Vladimir
