> > With this relatively new modular approach in libvirt - which service is > needed in order to migrate guests via tcp? > I am not sure what you mean with 'new modular'. I am still on el7 going to el9 this year. I am doing live migrations just with these. libvirtd.service enabled

[...] > - hypervisor drivers: > - virtqemud - for managing qemu machines > - virtlxcd - for lxc > - ... for all other hypervisor drivers... > - network driver > - virtnetworkd > - storage driver > - virtstoraged > - secret driver > - virtsecretd > > etc... > > If you are running modular daemons you then don't use 'libvirtd' at all, > but rather the client library communicates with the appropriate daemon > based on the object type. Further reading: https://libvirt.org/daemons.html

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.

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.

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.