On 29.05.26 00:29, Peter Xu wrote:
QEMU doesn't yet have a good way to specify migration parameters so that
they can be available even during early stage of QEMU boots. It is because
the migration object (who owns the migration parameters) will only be
created after PHASE_LATE_BACKENDS_CREATED. It means anything before it
reading migration parameters is illegal.
However, QEMU does have special use cases for such, namely only-migratable
flag, and cpr-transfer. Recently, we have one more possible user to read a
to-be-introduced new migration parameters during backend initialization
phase. We can introduce yet another global variable (or per-device
parameter) to bypass this limitation, but we can also seek for a generic
solution that we can setup migration parameters very early, even during
backend initializations.
See this discussion for more details on the context of the problem:
https://lore.kernel.org/r/[email protected]
This patch wants to take the latter approach.
As a start, introduce a new way to specify migration parameters in QEMU
boot commandline, as proposed in the above discussion:
-incoming config:key1=value1,key2=value2,...
Do I understand correctly, that with qobject_input_visitor_new_str(),
it automatically suuport also json-like syntax
-incoming config:'{"key1": "value1", "key2": {some more complex
structure}}'
?
When specified, QEMU will parse a string formatted MigrationParameters and
keep it. When migration object is created, it will apply all the settings
as initial value.
Since the application of boot parameters will be after object_new()
completes, it means it happens after all machine compat properties or
-global settings (which should be done during instance_post_init()).
[..]
to issuing the migrate\_incoming to allow the migration to begin.
+
+``-incoming config:key1=value1[,key2=value2,...]``
+
+ Specify migration parameters in QEMU commandlines, so that these
+ parameters will be available even during very early boot of QEMU.
+ They will be applied properly after QEMU boots and when the migration
+ core is initialized. From that POV, it has similar effect as setting
+ these parameters using QMP command ``migrate-set-parameters`` or HMP
+ command ``migrate_set_parameter``.
+
ERST
DEF("only-migratable", 0, QEMU_OPTION_only_migratable, \
So, to have a "defer" migration with preset parameter, I need two options
-incoming defer -incoming config:key=val
right?
--
Best regards,
Vladimir
