[libvirt PATCH 0/4] remote: switch to modular daemons by default

Daniel P. Berrangé posted 4 patches 2 years, 9 months ago
Test syntax-check failed
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/libvirt tags/patchew/20210610134317.368010-1-berrange@redhat.com
meson.build                         |   6 +-
meson_options.txt                   |   2 +-
src/libvirt_remote.syms             |   5 +
src/remote/remote_daemon_dispatch.c | 130 +------------------
src/remote/remote_sockets.c         | 192 ++++++++++++++++++++++++++--
src/remote/remote_sockets.h         |   7 +
6 files changed, 202 insertions(+), 140 deletions(-)
[libvirt PATCH 0/4] remote: switch to modular daemons by default
Posted by Daniel P. Berrangé 2 years, 9 months ago
This series first improves driver probing when using modular daemons.

Currently when URI is NULL, we connect to virtproxyd and it looks
at which UNIX sockets exist and what binaries exist, to decide which
modular hypervisor daemon to connect to.

This means the common case results in all traffic going via virtproxyd.
Moving the logic out of virtproxyd into the remote client means we can
avoid using virtproxyd by default.

With this, we can now switch to the modular daemons by default. The
latter change primarily impacts how autostart works

When running as root we simply connect to whatever UNIX socket exists
and rely on systemd to autostart if needed. Whether the UNIX sockets
are for the modular daemon or libvirt doesn't matter - we'll look for
both. Defaults are dependent on the distros' systemd presets. I intend
to get Fedora / RHEL-9 presets changed to use the modular daemons.

When running as non-root, we again try to connect to whatever UNIX
socket exists, whethe a modular daemon or libvirtd. When no socket
exists though, we need to pick a daemon to start and that's where
the meson default setting toggle comes into effect, so we prefer
spawning modular daemons now and don't spawn libvirtd.

Daniel P. Berrangé (4):
  remote: extract logic for probing for modular daemons
  remote: add support for probing drivers with modular daemons
  remote: remove probing logic from virtproxyd dispatcher
  remote: switch to auto-spawn modular daemons by default

 meson.build                         |   6 +-
 meson_options.txt                   |   2 +-
 src/libvirt_remote.syms             |   5 +
 src/remote/remote_daemon_dispatch.c | 130 +------------------
 src/remote/remote_sockets.c         | 192 ++++++++++++++++++++++++++--
 src/remote/remote_sockets.h         |   7 +
 6 files changed, 202 insertions(+), 140 deletions(-)

-- 
2.31.1


Re: [libvirt PATCH 0/4] remote: switch to modular daemons by default
Posted by Jim Fehlig 2 years, 9 months ago
On 6/10/21 7:43 AM, Daniel P. Berrangé wrote:
> This series first improves driver probing when using modular daemons.
> 
> Currently when URI is NULL, we connect to virtproxyd and it looks
> at which UNIX sockets exist and what binaries exist, to decide which
> modular hypervisor daemon to connect to.
> 
> This means the common case results in all traffic going via virtproxyd.
> Moving the logic out of virtproxyd into the remote client means we can
> avoid using virtproxyd by default.
> 
> With this, we can now switch to the modular daemons by default. The
> latter change primarily impacts how autostart works
> 
> When running as root we simply connect to whatever UNIX socket exists
> and rely on systemd to autostart if needed. Whether the UNIX sockets
> are for the modular daemon or libvirt doesn't matter - we'll look for
> both. Defaults are dependent on the distros' systemd presets. I intend
> to get Fedora / RHEL-9 presets changed to use the modular daemons.

I'll need to do the same for the SUSE presets, along with adjusting zypper 
patterns that include libvirtd, and other downstream tweaks. Additional testing 
may uncover other issues I haven't considered. I don't _think_ apparmor will 
prevent things from working since there are no profiles for the modular daemons. 
But yes, I'll need to work on some profiles :-).

Regards,
Jim


Re: [libvirt PATCH 0/4] remote: switch to modular daemons by default
Posted by Michal Prívozník 2 years, 9 months ago
On 6/10/21 3:43 PM, Daniel P. Berrangé wrote:
> This series first improves driver probing when using modular daemons.
> 
> Currently when URI is NULL, we connect to virtproxyd and it looks
> at which UNIX sockets exist and what binaries exist, to decide which
> modular hypervisor daemon to connect to.
> 
> This means the common case results in all traffic going via virtproxyd.
> Moving the logic out of virtproxyd into the remote client means we can
> avoid using virtproxyd by default.
> 
> With this, we can now switch to the modular daemons by default. The
> latter change primarily impacts how autostart works
> 
> When running as root we simply connect to whatever UNIX socket exists
> and rely on systemd to autostart if needed. Whether the UNIX sockets
> are for the modular daemon or libvirt doesn't matter - we'll look for
> both. Defaults are dependent on the distros' systemd presets. I intend
> to get Fedora / RHEL-9 presets changed to use the modular daemons.
> 
> When running as non-root, we again try to connect to whatever UNIX
> socket exists, whethe a modular daemon or libvirtd. When no socket
> exists though, we need to pick a daemon to start and that's where
> the meson default setting toggle comes into effect, so we prefer
> spawning modular daemons now and don't spawn libvirtd.
> 
> Daniel P. Berrangé (4):
>   remote: extract logic for probing for modular daemons
>   remote: add support for probing drivers with modular daemons
>   remote: remove probing logic from virtproxyd dispatcher
>   remote: switch to auto-spawn modular daemons by default
> 
>  meson.build                         |   6 +-
>  meson_options.txt                   |   2 +-
>  src/libvirt_remote.syms             |   5 +
>  src/remote/remote_daemon_dispatch.c | 130 +------------------
>  src/remote/remote_sockets.c         | 192 ++++++++++++++++++++++++++--
>  src/remote/remote_sockets.h         |   7 +
>  6 files changed, 202 insertions(+), 140 deletions(-)
> 

Reviewed-by: Michal Privoznik <mprivozn@redhat.com>

Michal