[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