libvirt users - Apr 2023 - which daemon/service for live migration - ?

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:
>>>> Hi guys.
>>>>
>>>> With this relatively new modular approach in libvirt - which
service is
>>>> needed in order to migrate guests via tcp?
>>> There is nothing special needed for migration when compared to
running a
>>> VM.
>>>
>>> With new daemons you need 'virtqemud' to manage the VM and
optionally
>>> 'virtnetworkd' if the VM uses libvirt-managed networks,
'virtstoraged'
>>> if it uses libvirt managed storage, and/or 'virtsecretd' if
it uses
>>> secrets storage.
>>>
>>> Configuration of daemon options moved to the appropriate per-daemon
>>> config file.
>>>
>> I have a feeling - have not tested all thoroughly - that specific
>> modules/daemons need to be up & running for specific methods of
>> transportation.
>> Say..
>> 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.
>>
>> 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"?

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.

thanks, L.

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.