On 22/06/2023 10.52, Juan Quintela wrote:
Paolo Bonzini <pbonz...@redhat.com> wrote:
On 6/12/23 22:51, Juan Quintela wrote:
Shall we just leave it there? Or is deprecating it helps us in any form?
See the patches two weeks ago when people complained that lisen(.., num)
was too low. And there are other parameters that work the same way
(that I convenientely had forgotten). So the easiest way to get things
right is to use "defer" always. Using -incoming "uri" should only be
for people that "know what they are doing", so we had to ways to do it:
- review all migration options and see which ones work without defer
and document it
- deprecate everything that is not defer.
"-incoming <uri>" is literally the same as running "migrate-incoming"
as the first thing on the monitor:
if (incoming) {
Error *local_err = NULL;
if (strcmp(incoming, "defer") != 0) {
qmp_migrate_incoming(incoming, &local_err);
if (local_err) {
error_reportf_err(local_err, "-incoming %s: ", incoming);
exit(1);
}
}
} else if (autostart) {
qmp_cont(NULL);
}
It's the only piece of code which distinguishes "-incoming defer" from
"-incoming <uri>".
So I'm not sure what the problem would be with keeping it?
User friendliness.
First of all, I use it all the time. And I know that it is useful for
developers. I was the one asking peter to implement -global
migration.foo to be able to test multifd with it.
The problem is that if you use more than two channels with multifd, on
the incoming side, you need to do:
- migrate_set_parameter multifd-channels 16
- migrate_incoming <uri>
And people continue to do:
- qemu -incoming <uri>
- migrate_set_parameter multifd-channels 16 (on the command line)
And they complain that it fails, because we are calling listen with the
wrong value.
Then simply forbid "migrate_set_parameter multifd-channels ..." if the uri
has been specified on the command line?
Thomas
