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://gitlab.com/peterx/qemu/-/pipelines/2560168907 > > > > > > > > > > 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. 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 -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
