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.
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
...
}
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
