which daemon/service for live migration - ?
Hi guys. With this relatively new modular approach in libvirt - which service is needed in order to migrate guests via tcp? many thanks, L.
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 virtlockd.socket enabled virtlogd.socket enabled
On Mon, Apr 17, 2023 at 10:15:00 +0000, Marc wrote:
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
'libvirtd' was separated into specific sub-daemons for specific object or hypervisor: - 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.
On Mon, Apr 17, 2023 at 12:49:09 +0200, Peter Krempa wrote:
On Mon, Apr 17, 2023 at 10:15:00 +0000, Marc wrote:
[...]
- 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
[...]
- 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:
Thanks for all the details in this thread. It will surely help when doing the upgrades and having a mixture of hosts with el7 and el9
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 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... A suggestion. thanks, L.
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 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.
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.
On Mon, Apr 17, 2023 at 16:38:17 +0200, lejeczek wrote:
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:
[...]
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'm sorry but 'migration' fairly and squarely fits into 'remote access' category IMO. The only reasonable way I can see this changed is to do e.g. Remote off-host (TLS socket) access ... Enumerating everything that needs it doesn't make much sense the document would become even more off-putting for others to read. Over recent times I've made a similar mistake with trying to improve the knowledge base page about debug logging to put every possible scenario based on what people were doing wrong, and the document is now so massive that people simple don't read it.
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.
TCP is insecure and deprecated and should not be used for any real use case.
participants (3)
-
lejeczek -
Marc -
Peter Krempa