22 Jun
2023
22 Jun
'23
5:22 a.m.
On 22/06/2023 10.52, Juan Quintela wrote:
> Paolo Bonzini <pbonzini@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