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.
