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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
