[RFC 4/6] migration: Deprecate -incoming <uri>

Thomas Huth thuth at redhat.com
Thu Jun 22 09:22:56 UTC 2023


On 22/06/2023 10.52, Juan Quintela wrote:
> Paolo Bonzini <pbonzini at 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



More information about the libvir-list mailing list