On Mon, Jun 12, 2023 at 10:51:08PM +0200, Juan Quintela wrote:
> Peter Xu <peterx@xxxxxxxxxx> 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@xxxxxxxxxx>
> >> ---
> >> 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 :|
