On Mon, Jun 12, 2023 at 10:51:08PM +0200, Juan Quintela wrote:
Peter Xu <peterx(a)redhat.com> wrote:
> On Mon, Jun 12, 2023 at 09:33:42PM +0200, Juan Quintela wrote:
>> Only "defer" is recommended. After setting all migation parameters,
>> start incoming migration with "migrate-incoming uri" command.
>>
>> Signed-off-by: Juan Quintela <quintela(a)redhat.com>
>> ---
>> docs/about/deprecated.rst | 7 +++++++
>> softmmu/vl.c | 2 ++
>> 2 files changed, 9 insertions(+)
>>
>> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
>> index 47e98dc95e..518672722d 100644
>> --- a/docs/about/deprecated.rst
>> +++ b/docs/about/deprecated.rst
>> @@ -447,3 +447,10 @@ The new way to modify migration is using migration
parameters.
>> ``blk`` functionality can be acchieved using
>> ``migrate_set_parameter block-incremental true``.
>>
>> +``-incoming uri`` (since 8.1)
>>
+'''''''''''''''''''''''''''''
>> +
>> +Everything except ``-incoming defer`` are deprecated. This allows to
>> +setup parameters before launching the proper migration with
>> +``migrate-incoming uri``.
>> +
>> diff --git a/softmmu/vl.c b/softmmu/vl.c
>> index b0b96f67fa..7fe865ab59 100644
>> --- a/softmmu/vl.c
>> +++ b/softmmu/vl.c
>> @@ -2651,6 +2651,8 @@ void qmp_x_exit_preconfig(Error **errp)
>> if (incoming) {
>> Error *local_err = NULL;
>> if (strcmp(incoming, "defer") != 0) {
>> + warn_report("-incoming %s is deprecated, use -incoming defer
and "
>> + " set the uri with migrate-incoming.",
incoming);
>
> I still use uri for all my scripts, alongside with "-global
migration.xxx"
> and it works.
You know what you are doing (TM).
And remember that we don't support -gobal migration.x-foo.
Yes, I know, we should drop the "x-" prefixes.
> 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.
Anything else is not going to be very user unfriendly.
What do you think.
In some cases it is worth having a convenience option for user friendliness.
In this case, however, users are already needing to use QMP/HMP on the
source side to set migration parameters. I think it is reasonable to say
that doing *exactly* the same with QMP/HMP on the destination side is
actually more friendly than requiring use of -global on the dest side
which is different syntax.
We don't document the way to use -global with migration parameters so
when people see '-incoming' I think we are steering them into a trap,
making it look like -incoming is sufficient on its own. Hence that user's
mistake recently about not setting migration parameters.
Overall I agree with deprecating '-incoming' != 'defer', as I think it
will better guide users to following the correct steps, as is not a
usability burden as they're already using QMP/HMP on the source side.
With regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|