which daemon/service for live migration - ?

[lejeczek]

On 17/04/2023 15:34, Peter Krempa wrote:
> On Mon, Apr 17, 2023 at 14:39:18 +0200, lejeczek wrote:
>>
>> On 17/04/2023 14:31, Peter Krempa wrote:
>>> On Mon, Apr 17, 2023 at 14:24:32 +0200, lejeczek wrote:
>>>> On 17/04/2023 12:27, Peter Krempa wrote:
>>>>> On Sun, Apr 16, 2023 at 08:54:57 +0200, lejeczek wrote:
> [...]
>
>>>> So I wonder - if that is the business logic here - if man pages which are
>>>> already are very good, could enhance even more to explain those bits too...
>>> The proxy daemon is necessary when you need very old clients which don't
>>> support the modular topology to work with the modern daemon topology.
>>>
>>> That's not a strict migration requirement though as you can run the
>>> migration from a modern client. In case you are migrating *from* an
>>> older daemon, that would mean that you can't use '--p2p' mode.
>>>
>> They are all the same - in my case - decently modern - in my mind - servers
>> & clients.
>> It is all Centos 9 Stream with everything from default repos up-to-date.
>> Are those "old"?
> No, that is fine. I forgot about the fact that 'virtproxyd' is required
> when you want to use TLS because I always use SSH as transport.
>
>> And even if so then my suggestion - to explain & include all that, that
>> modular relevance to certain operations, in man pages - I still share.
>> That will certainly safe admins like myself, good chunks of time.
> The man page for 'virtqemud' states in second paragraph:
>
>    The virtqemud daemon only listens for requests on a local Unix domain
>    socket. Remote off-host access and backwards compatibility with legacy
>    clients expecting libvirtd is provided by the virtproxy daemon.
>
> If you think more explanation is needed then please submit a issue and
> describe your request and suggestion how you'd like that to be worded.
>
I do. I did - I said that it appeared to be more specific.
I said:
"
migration with 'qemu+tls' fails if receiving node does not 
have 'virtproxyd-tls.socket' up&running,
even though 'virtproxyd.socket' & 'virtqemud.service' are 
running on that node.
"
I said - if that is the business logic, also for 'tcp' - 
then those would certainly be worth an explanation in man 
pages. Saves many some time.