Re: [PATCH v2 2/7] multifd: modifying 'migrate' qmp command to add multifd socket on particular src and dest pair

["Daniel P. Berrangé" <berrange@redhat.com>]

On Mon, Nov 21, 2022 at 01:26:55PM +0100, Juan Quintela wrote:
> Markus Armbruster <armbru@redhat.com> wrote:
> > Het Gala <het.gala@nutanix.com> writes:
> 
> 
> 
> Hi
> 
> >>>>   # Example:
> >>>>   #
> >>>> -# -> { "execute": "migrate", "arguments": { "uri": "tcp:0:4446" } }
> >>>> +# -> { "execute": "migrate",
> >>>> +#      "arguments": {
> >>>> +#          "uri": "tcp:0:4446",
> >>>> +#          "multi-fd-uri-list": [ { "source-uri": "tcp::6900",
> >>>> +#                                   "destination-uri": "tcp:0:4480",
> >>>> +#                                   "multifd-channels": 4},
> >>>> +#                                 { "source-uri": "tcp:10.0.0.0: ",
> >>>> +#                                   "destination-uri": "tcp:11.0.0.0:7789",
> >>>> +#                                   "multifd-channels": 5} ] } }
> 
> Why would one put the source uri and destination uri on the command?
> It looks more complicated to me, but I guess there is a good reason.
> 
> >>>
> >>> This whole scheme brings in redundancy wrt to the 'migrate-set-parameters'
> >>> API wrt multifd - essentally the same data is now being set in two
> >>> different places. IMHO, we should declare the 'multifd' capability
> >>> and the 'multifd-chanels' parameter deprecated, since the information
> >>> they provide is totally redundant, if you're giving an explicit list
> >>> of channels to 'migrate'.
> >>
> >> Hi Daniel. Initially while brainstorming this idea for the first
> >> time, we also came up with the same thought of depricating the
> >> migrate
> >> API. But how will we achieve this now and how is it going to
> >> work. Is it like we will be making migate V2 APIs initially,
> >> integrate it and then
> >> depricate the old one? would be happy to get some pointers from your end.
> >
> > Migration maintainers, please advise.
> 
> I would put the old one in top of the new one, and call it a day.
> I really hate the old one, but I haven't had the time to think about a
> better one (nor I have had the time to look into this one).
> 
> The problem that I am seing here is that we are adding the number of
> multifd channels here, and we were trying to not add migration
> parameters into the migrate command.

The issue of migration parameters is a much bigger one - a lot of them
should never have existed, if QEMU had a proper migration wire protocol
that could do feature negotiation.

We need to replace the wire protocol as the priority, at which point
the QMP side becomes simpler as a result. Starting with the QMP side,
without addressing the wire protocol first will never give us a good
long term result.

I've written more about that in my reply to Het's other patch.

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 :|