On 03/06/2026 18:15, Daniel P. Berrangé wrote:
On Wed, Jun 03, 2026 at 11:50:53AM -0400, Peter Xu wrote:
On Wed, Jun 03, 2026 at 10:48:54AM +0100, Daniel P. Berrangé wrote:
On Fri, May 29, 2026 at 10:15:35AM -0400, Peter Xu wrote:
On Thu, May 28, 2026 at 07:01:50PM -0300, Fabiano Rosas wrote:
Peter Xu <[email protected]> writes:
CI:
https://urldefense.proofpoint.com/v2/url?u=https-3A__gitlab.com_peterx_qemu_-2D_pipelines_2560168907&d=DwIDaQ&c=s883GpUCOChKOHiocYtGcg&r=c23RpsaH4D2MKyD3EPJTDa0BAxz6tV8aUJqVSoytEiY&m=kl69Otn4IxRhV6bx7NvgCZttOrO1SL4fZ-Qd3Jb-ODVtspTqSiQ6t1ujrrf-AB5J&s=nlkn4_NSgXkwTmC4JK_Le8z4ElYZ_cmlKRBCjJhTrIY&e=
This series introduces a generic way to specify migration parameters that
can be used even during the early boot phase of QEMU.
One example use case that already existed is CPR-transfer / CPR-exec.
currently QEMU has a temporary global variable (incoming_mode) to achieve
this, but it's hard to understand and this hack bleeded into quite a few
places that we could have avoided. The lines in patch 2 touched may
provide some idea.
With a generic approach of setting migration parameters with cmdlines, we
can remove this hack meanwhile QEMU should be able to keep the CPR behavior
as before. To CPR maintainers and reviewers: please have a closer look,
even better if it can be smoke tested, to see if this works for Oracle's
environment, TIA.
The 1st patch implemented that new semantics. It is straightforward: now
we can setup any migration parameter using an extra line of:
-incoming config:key1=value1,key2=value2,...
snip
- using "config:"
This makes it non-uniform with uri and channels which don't have a
keyword in front of them. I guess I could live with it, but it seems
odd. I see that it makes parsing way easier.
Yeah, having some identifier would be nice. I wished channels also have
identifiers if we don't need to keep compatibility.
IMHO having a magic "config:" prefix is an anti-pattern because it
involves custom command line parsing logic.
Yes, it's not elegant. I wished we had something like this though when
introducing the cpr channels; right now anything wasn't "defer" or URI
implies it's a "channel"..
I also wanted to avoid introducing new cmdline parameters, so migration
incoming cmdlines can stick with the same option. If there's better
suggestion please shoot.
Does "-incoming config" imply '-incoming defer' semantics or is it
independent ?
They're independent. Examples:
a) "-incoming config:* -incoming tcp:*", setup parameters for TCP incoming
migration without further deferral
b) "-incoming config:*" only, setup global parameters for a possible
upcoming outgoing migration
In that case they should definitely be independent command line
options. The old "-incoming" design is already broken / limited
in the non-'defer' case because it is hardcoded to use URI syntax
which can't express all the address formats we accept in QAPI
syntax. Adding more special cases onto -incoming just makes the
bad situation even worse and is not a forward looking design.
If we need the ability to specify migration parameters on the
CLI, then as a starting point for the design, we should assume that
-incoming does not exist, and design a complete solution from scratch
that uses QAPI exclusively, both for addresses and configuration.
Yes, absolutely. There has been a lot of effort to standardise our
parsing, so something that will accept the current (legacy?) -incoming
command line along with a new JSON notation allowing the extra
parameters feels like the right approach.
As discussed before, IMHO the "migrate" and "migrate-incoming"
commands need to accept both the address(s) and parameters/capabilities
as inline data items rather than relying on pre-configured global state
from the 'migrate-parameter' / 'migrate-capability' commands.
If we did that modelling for 'migrate-incoming' then that modelling of
command parmaeters could map directly to a new '-migrate-incoming'
command line argument that accepted exactly the same data model.
With regards,
Daniel
ATB,
Mark.
