qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: quintela@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 11:45:28 +0200	[thread overview]
Message-ID: <59f958ac-807d-e940-e5de-8109de62eb8c@redhat.com> (raw)
In-Reply-To: <87wmzv7ubn.fsf@secure.mitica>


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.

> - 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.

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.
> 
> 



  parent reply	other threads:[~2023-06-22  9:46 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 [this message]
2023-06-22 10:01             ` Juan Quintela
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=59f958ac-807d-e940-e5de-8109de62eb8c@redhat.com \
    --to=pbonzini@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=peterx@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).