qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Juan Quintela <quintela@redhat.com>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
	qemu-devel@nongnu.org, "Markus Armbruster" <armbru@redhat.com>,
	"Leonardo Bras" <leobras@redhat.com>,
	"Daniel P.Berrangé" <berrange@redhat.com>,
	qemu-block@nongnu.org, "Stefan Hajnoczi" <stefanha@redhat.com>,
	"Eric Blake" <eblake@redhat.com>, "Fam Zheng" <fam@euphon.net>,
	"Thomas Huth" <thuth@redhat.com>,
	libvir-list@redhat.com
Subject: Re: [RFC 4/6] migration: Deprecate -incoming <uri>
Date: Thu, 22 Jun 2023 11:24:18 -0400	[thread overview]
Message-ID: <ZJRnokKh47xe/4CE@x1n> (raw)
In-Reply-To: <87sfaj7r3g.fsf@secure.mitica>

On Thu, Jun 22, 2023 at 12:01:55PM +0200, Juan Quintela wrote:
> Paolo Bonzini <pbonzini@redhat.com> wrote:
> > On 6/22/23 10:52, Juan Quintela wrote:
> >> User friendliness.
> >> The problem is that if you use more than two channels with multifd, on
> >> the incoming side, you need to do:
> >
> > You're sacrificing user-friendliness for the 99.99% that don't use
> > multifd, for an error (i.e. it's not even fixing the issue) for the
> > 0.01% that use multifd.  That's not user-friendly.
> 
> You are forgeting of the 0.01% that uses postocopy preempt (that is easy
> just changing the default value to 2), and the 0.0000001% that uses
> compression (they have exactly the same problem with compress_threads,
> compress_zlib, etc).
> 
> >> - migrate_set_parameter multifd-channels 16
> >> - migrate_incoming <uri>
> >> 
> >>> The issue is not how many features the command line has, but how
> >>> they're implemented.
> >> Or if they are confusing for the user?
> >
> > Anyone using multifd is not a typical user anyway.
> 
> >>> If they're just QMP wrappers and as such they're self-contained in
> >>> softmmu/vl.c, that's fine.
> >>>
> >>> In fact, even for parameters, we could use keyval to parse "-incoming"
> >> What is keyval?
> >
> > util/keyval.c and include/qemu/keyval.h.  It parses a list of
> > key=value pairs into a QDict.  Once you have removed the "source" key
> > from the QDict you can use a visitor to parse the rest into a
> > MigrateSetParameters.  See the handling of QEMU_OPTION_audio, it could
> > be something like
> >
> >
> >             case QEMU_OPTION_incoing: {
> >                 Visitor *v;
> >                 MigrateSetParameters *incoming_params = NULL;
> >                 QDict *dict = keyval_parse(optarg, "source", NULL,
> >                 &error_fatal);
> >
> >                 if (incoming) {
> >                     if (qdict_haskey(dict, "source")) {
> >                         error_setg(&error_fatal, "Parameter 'source'
> >                         is duplicate");
> >                     }
> >                 } else {
> >                     if (!qdict_haskey(dict, "source")) {
> >                         error_setg(&error_fatal, "Parameter 'source'
> >                         is missing");
> >                     }
> >                     runstate_set(RUN_STATE_INMIGRATE);
> >                     incoming = g_strdup(qdict_get_str(dict, "source"));
> >                     qdict_del(dict, "source");
> >                 }
> >
> >                 v = qobject_input_visitor_new_keyval(QOBJECT(dict));
> >                 qobject_unref(dict);
> >                 visit_type_MigrateSetParameters(v, NULL,
> >                 &incoming_params, &error_fatal);
> >                 visit_free(v);
> >                 qmp_migration_set_parameters(incoming_params,

PS: we may want to postpone this to be later than migration_object_init(),
when/if there's a real patch.

> >                 &error_fatal);
> >                 qapi_free_MigrateSetParameters(incoming_params);
> >             }
> >
> >
> > For example "-incoming [source=]tcp:foo,multifd-channels=16" would
> > desugar to
> >
> >   migrate_set_parameter multifd-channels 16
> >   migrate_incoming tcp:foo
> >
> > The only incompatibility is for people who are using "," in an URI,
> > which is rare and only an issue for the "exec" protocol.

If we worry on breaking anyone, we can apply the keyval parsing only when
!exec.  Not sure whether it matters a huge lot..

> 
> Aha, that makes sense.  And will allow us to deprecate/remove the
> --global migration.* stuff.

We may still need a way to set the caps/params for src qemu?..

Thanks,

-- 
Peter Xu



  reply	other threads:[~2023-06-22 15:25 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-12 19:33 [RFC 0/6] Migration deprecated parts Juan Quintela
2023-06-12 19:33 ` [RFC 1/6] migration: skipped field is really obsolete Juan Quintela
2023-06-20 12:01   ` Daniel P. Berrangé
2023-06-22 17:49     ` Juan Quintela
2023-06-12 19:33 ` [RFC 2/6] migration: migrate 'inc' command option is deprecated Juan Quintela
2023-06-20 12:05   ` Daniel P. Berrangé
2023-06-22 18:11     ` Juan Quintela
2023-06-12 19:33 ` [RFC 3/6] migration: migrate 'blk' " Juan Quintela
2023-06-20 12:06   ` Daniel P. Berrangé
2023-06-22 18:12     ` Juan Quintela
2023-06-12 19:33 ` [RFC 4/6] migration: Deprecate -incoming <uri> Juan Quintela
2023-06-12 19:41   ` Peter Xu
2023-06-12 20:51     ` Juan Quintela
2023-06-12 21:19       ` Peter Xu
2023-06-20 12:13         ` Daniel P. Berrangé
2023-06-22 19:34         ` Juan Quintela
2023-06-20 12:10       ` Daniel P. Berrangé
2023-06-20 14:45         ` Peter Xu
2023-06-22  8:28       ` Paolo Bonzini
2023-06-22  8:52         ` Juan Quintela
2023-06-22  9:22           ` Thomas Huth
2023-06-22 15:25             ` Peter Xu
2023-06-22 19:37               ` Juan Quintela
2023-06-22  9:45           ` Paolo Bonzini
2023-06-22 10:01             ` Juan Quintela
2023-06-22 15:24               ` Peter Xu [this message]
2023-06-22 16:03                 ` Paolo Bonzini
2023-06-22  9:59           ` Daniel P. Berrangé
2023-06-22 15:54             ` Peter Xu
2023-06-22 16:33               ` Daniel P. Berrangé
2023-06-22 19:20                 ` Peter Xu
2023-06-23  7:17                   ` Daniel P. Berrangé
2023-06-23 14:34                     ` Peter Xu
2023-06-23  8:23               ` Daniel P. Berrangé
2023-06-23 14:51                 ` Peter Xu
2023-06-23 15:03                   ` Daniel P. Berrangé
2023-06-21  7:08   ` Thomas Huth
2023-06-22  2:22     ` Juan Quintela
2023-06-22  8:30     ` Paolo Bonzini
2023-06-22 18:12   ` Juan Quintela
2023-06-12 19:33 ` [RFC 5/6] migration: Deprecate block migration Juan Quintela
2023-06-21 11:45   ` Stefan Hajnoczi
2023-06-22 18:17     ` Juan Quintela
2023-06-12 19:33 ` [RFC 6/6] migration: Deprecated old compression method Juan Quintela
2023-06-21  7:14   ` Thomas Huth
2023-06-22 19:21     ` Juan Quintela
2023-06-21 10:31   ` Daniel P. Berrangé
2023-06-22 19:32     ` Juan Quintela
2023-06-13  7:48 ` [RFC 0/6] Migration deprecated parts Jiri Denemark

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZJRnokKh47xe/4CE@x1n \
    --to=peterx@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=eblake@redhat.com \
    --cc=fam@euphon.net \
    --cc=leobras@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).