This is a draft document that was built and uploaded automatically. It may document beta software and be incomplete or even incorrect. Use this document at your own risk.

Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Virtualization Guide / Managing virtual machines with libvirt / libvirt daemons
Applies to SUSE Linux Enterprise Server 15 SP5

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. The monolithic daemon is enabled by default, but a deployment can be switched to modular daemons by disabling libvirtd and enabling the desired individual daemons.

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 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.2 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.

Like the monolithic daemon, the modular daemons are managed with several 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.3 Switching to modular daemons

  

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

  1. Stop the monolithic daemon and its sockets 

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

  2. Disable future start of the monolithic daemon 

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

  3. Enable the modular daemons for KVM or Xen, including the desired secondary daemons. The following example enables the QEMU daemon for KVM and all the secondary daemons except the interface daemon: 

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

  4. Start the sockets for the same set of daemons 

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

  5. If connections from remote hosts need to be supported, the virtproxyd daemon must be enabled and started: 

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