[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 2/7] multifd: modifying 'migrate' qmp command to add multi
From: |
Daniel P . Berrangé |
Subject: |
Re: [PATCH v2 2/7] multifd: modifying 'migrate' qmp command to add multifd socket on particular src and dest pair |
Date: |
Tue, 22 Nov 2022 09:26:47 +0000 |
User-agent: |
Mutt/2.2.7 (2022-08-07) |
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 :|