[libvirt] [PATCH 19/41] remote: introduce virtproxyd daemon to handle IP connectivity
Jim Fehlig
JFEHLIG at suse.com
Mon Jul 29 14:26:18 UTC 2019
On 7/23/19 10:02 AM, Daniel P. Berrangé wrote:
> The libvirtd daemon provides the traditional libvirt experience where
> all the drivers are in a single daemon, and is accessible over both
> local UNIX sockets and remote IP sockets.
>
> In the new world we're having a set of per-driver daemons which will
> primarily be accessed locally via their own UNIX sockets.
>
> We still, however, need to allow for case of applications which will
> connect to libvirt remotely. These remote connections can be done as
> TCP/TLS sockets, or by SSH tunnelling to the UNIX socket.
>
> In the later case, the old libvirt.so clients will only know about
> the path to the old libvirtd socket /var/run/libvirt/libvirt-sock,
> and not the new driver sockets /var/run/libvirt/virtqemud-sock.
>
> It is also not desirable to expose the main driver specific daemons
> over IP directly to minimize their attack service.
>
> Thus the virtproxyd daemon steps into place, to provide TCP/TLS sockets,
> and back compat for the old libvirtd UNIX socket path(s). It will then
> forward all RPC calls made to the appropriate driver specific daemon.
>
> Essentially it is equivalent to the old libvirtd with absolutely no
> drivers registered except for the remote driver (and other stateless
> drivers in libvirt.so).
>
> We could have modified libvirtd so none of the drivers are registed
> to get the same end result. We could even add a libvirtd.conf parameter
> to control whether the drivers are loaded to enable users to switch back
> to the old world if we discover bugs in the split-daemon model. Using a
> new daemon though has some advantages
>
> - We can make virtproxyd and the virtXXXd per-driver daemons all
> have "Conflicts: libvirtd.service" in their systemd unit files.
> This will guarantee that libvirtd is never started at the same
> time, as this would result in two daemons running the same driver.
> Fortunately drivers use locking to protect themselves, but it is
> better to avoid starting a daemon we know will conflict.
>
> - It allows us to break CLI compat to remove the --listen parameter.
> Both listen_tcp and listen_tls parameters in /etc/libvirtd/virtd.conf
> will default to zero. Either TLS or TCP can be enabled exclusively
> though virtd.conf without requiring the extra step of adding --listen.
>
> - It allows us to set a strict SELinux policy over virtproxyd. For
> back compat the libvirtd policy must continue to allow all drivers
> to run. We can't easily give a second policy to libvirtd which
> locks it down. By introducing a new virtproxyd we can set a strict
> policy for that daemon only.
Reading this paragraph reminds me that the apparmor profiles will need adjusting
too.
Regards,
Jim
More information about the libvir-list
mailing list