Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
documentation.suse.com / Documentação do SUSE Linux Enterprise Server / Virtualization Guide / Managing virtual machines with libvirt / libvirt daemons
Applies to SUSE Linux Enterprise Server 15 SP6

8 libvirt daemons

 

A libvirt deployment for accessing KVM or Xen requires one or more daemons to be installed and active on the host. libvirt provides two daemon deployment options: monolithic or modular daemons. libvirt has always provided the single monolithic daemon libvirtd. It includes the primary hypervisor drivers and all secondary drivers needed for managing storage, networking, node devices, etc. The monolithic libvirtd also provides secure remote access for external clients. Over time, libvirt added support for modular daemons, where each driver runs in its own daemon, allowing users to customize their libvirt deployment. Modular daemons are enabled by default, but a deployment can be switched to the traditional monolithic daemon by disabling the individual daemons and enabling libvirtd.

The modular daemon deployment is useful in scenarios where minimal libvirt support is needed. For example, if virtual machine storage and networking is not provided by libvirt, the libvirt-daemon-driver-storage and libvirt-daemon-driver-network packages are not required. Kubernetes is an example of an extreme case, where it handles all networking, storage, cgroups and namespace integration, etc. Only the libvirt-daemon-driver-QEMU package, providing virtqemud, needs to be installed. Modular daemons allow configuring a custom libvirt deployment containing only the components required for the use case.

8.1 Starting and stopping the modular daemons

 

The modular daemons are named after the driver which they are running, with the pattern “virtDRIVERd”. They are configured via the files /etc/libvirt/virtDRIVERd.conf. SUSE supports the virtqemud and virtxend hypervisor daemons, along with all the secondary daemons:

  • virtnetworkd - The virtual network management daemon which provides libvirt's virtual network management APIs. For example, virtnetworkd can be used to create a NAT virtual network on the host for use by virtual machines.

  • virtnodedevd - The host physical device management daemon which provides libvirt's node device management APIs. For example, virtnodedevd can be used to detach a PCI device from the host for use by a virtual machine.

  • virtnwfilterd - The host firewall management daemon which provides libvirt's firewall management APIs. For example, virtnwfilterd can be used to configure network traffic filtering rules for virtual machines.

  • virtsecretd - The host secret management daemon which provides libvirt's secret management APIs. For example, virtsecretd can be used to store a key associated with a LUKs volume.

  • virtstoraged - The host storage management daemon which provides libvirt's storage management APIs. virtstoraged can be used to create storage pools and create volumes from those pools.

  • virtinterfaced - The host NIC management daemon which provides libvirt's host network interface management APIs. For example, virtinterfaced can be used to create a bonded network device on the host. SUSE discourages the use of libvirt's interface management APIs in favor of default networking tools like wicked or NetworkManager. It is recommended to disable virtinterfaced.

  • virtproxyd - A daemon to proxy connections between the traditional libvirtd sockets and the modular daemon sockets. With a modular libvirt deployment, virtproxyd allows remote clients to access the libvirt APIs similar to the monolithic libvirtd. It can also be used by local clients that connect to the monolithic libvirtd sockets.

  • virtlogd - A daemon to manage logs from virtual machine consoles. virtlogd is also used by the monolithic libvirtd. The monolithic daemon and virtqemud systemd unit files require virtlogd, so it is not necessary to explicitly start virtlogd.

  • virtlockd - A daemon to manage locks held against virtual machine resources such as disks. virtlockd is also used by the monolithic libvirtd. The monolithic daemon, virtqemud, and virtxend systemd unit files require virtlockd, so it is not necessary to explicitly start virtlockd.

virtlogd and virtlockd are also used by the monolithic libvirtd. These daemons have always been separate from libvirtd for security reasons.

By default, the modular daemons listen for connections on the /var/run/libvirt/virtDRIVERd-sock and /var/run/libvirt/virtDRIVERd-sock-ro Unix Domain Sockets. The client library prefers these sockets over the traditional /var/run/libvirt/libvirtd-sock. The virtproxyd daemon is available for remote clients or local clients expecting the traditional libvirtd socket.

The virtqemud and virtxend services are enabled in the systemd presets. The sockets for virtnetworkd, virtnodedevd, virtnwfilterd, virtstoraged and virtsecretd are also enabled in the presets, ensuring the daemons are enabled and available when the corresponding packages are installed. Although enabled in presets for convenience, the modular daemons can also be managed with their systemd unit files:

  • virtDRIVERd.service - The main unit file for launching the virtDRIVERd daemon. We recommend configuring the service to start on boot if VMs are also configured to start on host boot.

  • virtDRIVERd.socket - The unit file corresponding to the main read-write UNIX socket /var/run/libvirt/virtDRIVERd-sock. We recommend starting this socket on boot by default.

  • virtDRIVERd-ro.socket - The unit file corresponding to the main read-only UNIX socket /var/run/libvirt/virtDRIVERd-sock-ro. We recommend starting this socket on boot by default.

  • virtDRIVERd-admin.socket - The unit file corresponding to the administrative UNIX socket /var/run/libvirt/virtDRIVERd-admin-sock. We recommend starting this socket on boot by default.

When systemd socket activation is used, several configuration settings in virtDRIVERd.conf are no longer honored. Instead, these settings must be controlled via the system unit files:

  • unix_sock_group - UNIX socket group owner, controlled via the SocketGroup parameter in the virtDRIVERd.socket and virtDRIVERd-ro.socket unit files.

  • unix_sock_ro_perms - Read-only UNIX socket permissions, controlled via the SocketMode parameter in the virtDRIVERd-ro.socket unit file.

  • unix_sock_rw_perms - Read-write UNIX socket permissions, controlled via the SocketMode parameter in the virtDRIVERd.socket unit file.

  • unix_sock_admin_perms - Admin UNIX socket permissions, controlled via the SocketMode parameter in the virtDRIVERd-admin.socket unit file.

  • unix_sock_dir - Directory in which all UNIX sockets are created, independently controlled via the ListenStream parameter in any of the virtDRIVERd.socket, virtDRIVERd-ro.socket and virtDRIVERd-admin.socket unit files.

8.2 Starting and stopping the monolithic daemon

 

The monolithic daemon is known as libvirtd and is configured via /etc/libvirt/libvirtd.conf. libvirtd is managed with several systemd unit files:

  • libvirtd.service - The main systemd unit file for launching libvirtd. We recommend configuring libvirtd.service to start on boot if VMs are also configured to start on host boot.

  • libvirtd.socket - The unit file corresponding to the main read-write UNIX socket /var/run/libvirt/libvirt-sock. We recommend enabling this unit on boot.

  • libvirtd-ro.socket - The unit file corresponding to the main read-only UNIX socket /var/run/libvirt/libvirt-sock-ro. We recommend enabling this unit on boot.

  • libvirtd-admin.socket - The unit file corresponding to the administrative UNIX socket /var/run/libvirt/libvirt-admin-sock. We recommend enabling this unit on boot.

  • libvirtd-tcp.socket - The unit file corresponding to the TCP 16509 port for non-TLS remote access. This unit should not be configured to start on boot until the administrator has configured a suitable authentication mechanism.

  • libvirtd-tls.socket - The unit file corresponding to the TCP 16509 port for TLS remote access. This unit should not be configured to start on boot until the administrator has deployed x509 certificates and optionally configured a suitable authentication mechanism.

When systemd socket activation is used, certain configuration settings in libvirtd.conf are no longer honored. Instead, these settings must be controlled via the system unit files:

  • listen_tcp - TCP socket usage is enabled by starting the libvirtd-tcp.socket unit file.

  • listen_tls - TLS socket usage is enabled by starting the libvirtd-tls.socket unit file.

  • tcp_port - Port for the non-TLS TCP socket, controlled via the ListenStream parameter in the libvirtd-tcp.socket unit file.

  • tls_port - Port for the TLS TCP socket, controlled via the ListenStream parameter in the libvirtd-tls.socket unit file.

  • listen_addr - IP address to listen on, independently controlled via the ListenStream parameter in the libvirtd-tcp.socket or libvirtd-tls.socket unit files.

  • unix_sock_group - UNIX socket group owner, controlled via the SocketGroup parameter in the libvirtd.socket and libvirtd-ro.socket unit files.

  • unix_sock_ro_perms - Read-only UNIX socket permissions, controlled via the SocketMode parameter in the libvirtd-ro.socket unit file.

  • unix_sock_rw_perms - Read-write UNIX socket permissions, controlled via the SocketMode parameter in the libvirtd.socket unit file.

  • unix_sock_admin_perms - Admin UNIX socket permissions, controlled via the SocketMode parameter in the libvirtd-admin.socket unit file.

  • unix_sock_dir - Directory in which all UNIX sockets are created, independently controlled via the ListenStream parameter in any of the libvirtd.socket, libvirtd-ro.socket and libvirtd-admin.socket unit files.

Important
Important: Conflicting services: libvirtd and xendomains

If libvirtd fails to start, check if the service xendomains is loaded: 

> systemctl is-active xendomains active

If the command returns active, you need to stop xendomains before you can start the libvirtd daemon. If you want libvirtd to also start after rebooting, additionally prevent xendomains from starting automatically. Disable the service: 

> sudo systemctl stop xendomains
> sudo systemctl disable xendomains
> sudo systemctl start libvirtd

xendomains and libvirtd provide the same service and when used in parallel, may interfere with one another. As an example, xendomains may attempt to start a domU already started by libvirtd.

8.3 Switching to the monolithic daemon

 

Several services need to be changed when switching from modular to the monolithic daemon. It is recommended to stop or evict any running virtual machines before switching between the daemon options.

  1. Stop the modular daemons and their sockets. The following example disables the QEMU daemon for KVM and several secondary daemons. 

    for drv in qemu network nodedev nwfilter secret storage
do
 > sudo systemctl stop virt${drv}d.service
 > sudo systemctl stop virt${drv}d{,-ro,-admin}.socket
done

  2. Disable future start of the modular daemons 

    for drv in qemu network nodedev nwfilter secret storage
do
 > sudo systemctl disable virt${drv}d.service
 > sudo systemctl disable virt${drv}d{,-ro,-admin}.socket
done

  3. Enable the monolithic libvirtd service and sockets 

    > sudo systemctl enable libvirtd.service
> sudo systemctl enable libvirtd{,-ro,-admin}.socket

  4. Start the monolithic libvirtd sockets 

    > sudo systemctl start libvirtd{,-ro,-admin}.socket