From: Juan Quintela <quintela@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Peter Xu" <peterx@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 12:01:55 +0200 [thread overview]
Message-ID: <87sfaj7r3g.fsf@secure.mitica> (raw)
In-Reply-To: <59f958ac-807d-e940-e5de-8109de62eb8c@redhat.com> (Paolo Bonzini's message of "Thu, 22 Jun 2023 11:45:28 +0200")
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,
> &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.
Aha, that makes sense. And will allow us to deprecate/remove the
--global migration.* stuff.
Thanks very much.
See why this was an RFC O:-)
Later, Juan.
>
> Paolo
>
>>> and
>>> set the parameters in the same place as above. That would remove the need
>>> for "-global migration".
>> Could you elaborate?
>
>
>
>> The other option that I can think of is changing the error messages for
>> migrate_check_parameters() and give instructions that you can't set
>> multifd channels once that you have started incoming migration.
>> Explaining there to use migrate_incoming command?
>> Later, Juan.
>>
next prev parent reply other threads:[~2023-06-22 10:02 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 [this message]
2023-06-22 15:24 ` Peter Xu
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=87sfaj7r3g.fsf@secure.mitica \
--to=quintela@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=peterx@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--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).