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.
