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
ContentsContents
Virtualization Guide
  1. Preface
  2. I Introduction
    1. 1 Virtualization technology
    2. 2 Virtualization scenarios
    3. 3 Introduction to Xen virtualization
    4. 4 Introduction to KVM virtualization
    5. 5 Virtualization tools
    6. 6 Installation of virtualization components
  3. II Managing virtual machines with libvirt
    1. 7 libvirt daemons
    2. 8 Preparing the VM Host Server
    3. 9 Guest installation
    4. 10 Basic VM Guest management
    5. 11 Connecting and authorizing
    6. 12 Advanced storage topics
    7. 13 Configuring virtual machines with Virtual Machine Manager
    8. 14 Configuring virtual machines with virsh
    9. 15 Xen to KVM migration guide
  4. III Hypervisor-independent features
    1. 16 Disk cache modes
    2. 17 VM Guest clock settings
    3. 18 libguestfs
    4. 19 QEMU guest agent
    5. 20 Software TPM emulator
    6. 21 Creating crash dumps of a VM Guest
  5. IV Managing virtual machines with Xen
    1. 22 Setting up a virtual machine host
    2. 23 Virtual networking
    3. 24 Managing a virtualization environment
    4. 25 Block devices in Xen
    5. 26 Virtualization: configuration options and settings
    6. 27 Administrative tasks
    7. 28 XenStore: configuration database shared between domains
    8. 29 Xen as a high-availability virtualization host
    9. 30 Xen: converting a paravirtual (PV) guest into a fully virtual (FV/HVM) guest
  6. V Managing virtual machines with QEMU
    1. 31 QEMU overview
    2. 32 Setting up a KVM VM Host Server
    3. 33 Guest installation
    4. 34 Running virtual machines with qemu-system-ARCH
    5. 35 Virtual machine administration using QEMU monitor
  7. VI Troubleshooting
    1. 36 Integrated help and package documentation
    2. 37 Gathering system information and logs
  8. Glossary
  9. A Configuring GPU Pass-Through for NVIDIA cards
  10. B GNU licenses
Navigation←→
Virtualization Guide › Managing virtual machines with libvirt › libvirt daemons
Top
←→
Applies to openSUSE Leap 15.5

7 libvirt daemons Edit source

7.1 Starting and stopping the monolithic daemon
7.2 Starting and stopping the modular daemons
7.3 Switching to modular 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 supporting secondary drivers needed for storage, such as networking, node device and management. The monolithic libvirtd also provides secure remote access for external clients. With modular daemons, each driver runs in its own daemon, allowing users to customize their libvirt deployment. By default, the monolithic daemon is enabled, but a deployment can be switched to modular daemons by managing the corresponding systemd service files.

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 type of 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.

7.1 Starting and stopping the monolithic daemon Edit source

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.

7.2 Starting and stopping the modular daemons Edit source

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

libvirt contains two modular daemons that are also used by the monolithic libvirtd, virtlockd and virtlogd.

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.

7.3 Switching to modular daemons Edit source

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 new daemons for KVM or Xen, including the required secondary drivers. The following example enables the QEMU driver for KVM and all the required secondary drivers: 

    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
→Chapter 8 Preparing the VM Host Server←Part II Managing virtual machines with libvirt
Print this page

© 2023 SUSE