February 2020 - Devel - Libvirt List Archives

[PATCH 0/3] remove dimm auto-align on hotplug/unplug

by Daniel Henrique Barboza

This series fixes bug [1]. See patch 2 for details. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1780506 Daniel Henrique Barboza (3): qemu_domain.c: make qemuDomainGetMemoryModuleSizeAlignment() public qemu_hotplug.c: remove dimm auto-align on hotplug/unplug qemu_domain.c: remove qemuDomainMemoryDeviceAlignSize() src/qemu/qemu_domain.c | 23 +++-------------------- src/qemu/qemu_domain.h | 4 ++-- src/qemu/qemu_hotplug.c | 23 +++++++++++++++++++++-- 3 files changed, 26 insertions(+), 24 deletions(-) -- 2.24.1

4 years, 2 months

1
4
0 / 0

[PATCH v2 0/3] Tighten qemu-img rules on missing backing format

by Eric Blake

4 years, 2 months

3
14
0 / 0

[libvirt PATCH] docs: add page describing the libvirt daemons

by Daniel P. Berrangé

Now that we have more than just the libvirtd daemon, we should be explaining to users what they are all for & important aspects of their configuration. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- docs/daemons.rst | 682 ++++++++++++++++++++++++++++++++++++++++++++++ docs/docs.html.in | 3 + 2 files changed, 685 insertions(+) create mode 100644 docs/daemons.rst diff --git a/docs/daemons.rst b/docs/daemons.rst new file mode 100644 index 0000000000..a74b228025 --- /dev/null +++ b/docs/daemons.rst @@ -0,0 +1,682 @@ +=============== +Libvirt Daemons +=============== + +.. contents:: + +A libvirt deployment for accessing one of the stateful drivers will require +one or more daemons to be deployed on the virtualization host. There are a +number of ways the daemons can be configured which will be outlined in this +page. + +Architectural options +===================== + +Monolithic vs modular daemons +----------------------------- + +Traditionally libvirt provided a single monolithic daemon called ``libvirtd`` +which exposed support for all the stateful drivers, both primary hypervisor +drivers and secondary supporting drivers. It also enables secure remote access +from clients running off host. + +Work is underway for the monolithic daemon to be replaced by a new set of +modular daemons ``virt${DRIVER}d``, each one servicing a single stateful +driver. A further ``virtproxyd`` daemon will provide secure remote access, as +well as backcompatibility for clients using the UNIX socket path of the +monolithic daemon. + +The change to modular daemons should not affect API functionality used by +management applications. It will, however, have an impact on host provisioning +tools since there are new systemd services and configuration files to be +managed. + +Currently both monolithic and modular daemons are built by default, but the RPC +client still prefers connecting to the monolithic daemon. It is intended to +switch the RPC client to prefer the modular daemons in the near future. At +least 1 year after this switch (but not more than 2 years), the monolithic +daemon will be deleted entirely. + +Operating modes +--------------- + +The libvirt daemons, whether monolithic or modular, can often operate in two +modes + +* *System mode* - the daemon is running as the root user account, enabling + access to its full range of functionality. A read-write connection to + daemons in system mode **typically implies privileges equivalent to having + a root shell**. Suitable `authentication mechanisms <auth.html>`__ **must + be enabled** to secure it against untrustworthy clients/users. + +* *Session mode* - the daemon is running as any non-root user account, + providing access to a more restricted range of functionality. Only client + apps/users running under **the same UID are permitted to connect**, thus a + connection does not imply any elevation of privileges. + + Not all drivers support session mode and as such the corresponding + modular daemon may not support running in this mode + + +Monolithic driver daemon +======================== + +The monolithic daemon is known as ``libvirtd`` and has historically been the +default in libvirt. It is configured via the file ``/etc/libvirt/libvirtd.conf`` + + +Monolithic sockets +------------------ + +When running in system mode, ``libvirtd`` exposes three UNIX domain sockets, and +optionally, one or two TCP sockets + +* ``/var/run/libvirt/libvirt-sock`` - the primary socket for accessing libvirt + APIs, with full read-write privileges. A connection to this socket gives the + client privileges that are equivalent to having a root shell. This is the + socket that most management applications connect to by default. + +* ``/var/run/libvirt/libvirt-sock-ro`` - the secondary socket for accessing + libvirt APIs, with limited read-only privileges. A connection to this socket + gives the ability to query the existance of objects and monitor some aspects + of their operation. This is the socket that most management applications + connect to when requesting read only mode. Typically this is what a + monitoring app would use. + +* ``/var/run/libvirt/libvirt-admin-sock`` - the administrative socket for + controlling operation of the daemon itself (as opposed to drivers it is + running). This can be used to dynamically reconfigure some aspects of the + daemon and monitor/control connected clients. + +* ``TCP 16509`` - the non-TLS socket for remotely accessing the libvirt APIs, + with full read-write privileges. A connection to this socket gives the + client privileges that are equivalent to having a root shell. Since it does + not use TLS, an `authentication mechanism <auth.html>`__ that provides + encryption must be used. Only the GSSAPI/Kerberos mechanism is capable of + satisfying this requirement. In general applications should not use this + socket except for debugging in a development/test environment. + +* ``TCP 16514`` - the TLS socket for remotely accessing the libvirt APIs, + with full read-write privileges. A connection to this socket gives the + client privileges that are equivalent to having a root shell. Access control + can be enforced either through validation of `x509 certificates + <tlscerts.html>`__, and/or by enabling an `authentication mechanism + <auth.html>`__. + +NB, some distros will use ``/run`` instead of ``/var/run``. + +When running in session mode, ``libvirtd`` exposes two UNIX domain sockets + +* ``$XDG_RUNTIME_DIR/libvirt/libvirt-sock`` - the primary socket for accessing + libvirt APIs, with full read-write privileges. A connection to this socket + does not alter the privileges that the client already has. This is the + socket that most management applications connect to by default. + +* ``$XDG_RUNTIME_DIR/libvirt/libvirt-admin-sock`` - the administrative socket + for controlling operation of the daemon itself (as opposed to drivers it is + running). This can be used to dynamically reconfigure some aspects of the + daemon and monitor/control connected clients. + +Notice that the session mode does not have a separate read-only socket. Since +the clients must be running as the same user as the daemon itself, there is +not any security benefit from attempting to enforce a read-only mode. + +``$XDG_RUNTIME_DIR`` commonly points to a per-user private location on tmpfs, +such as ``/run/user/$UID``. + + +Monolithic Systemd Integration +------------------------------ + +When the ``libvirtd`` daemon is managed by ``systemd`` a number of desirable +features are available, most notably socket activation. + +Libvirt ships a number of unit files for controlling libvirtd + +* ``libvirtd.service`` - the main unit file for launching the libvirtd daemon + in system mode. The command line arguments passed can be configured by + editting ``/etc/sysconfig/libvirtd``. This is typically only needed to control + the use of the auto shutdown timeout value. It is recommended that this + service unit be configured to start on boot. This is because various + libvirt drivers support autostart of their objects. If it is known that + autostart is not required, this unit can be left to start on demand. + +* ``libvirtd.socket`` - the unit file corresponding to the main read-write + UNIX socket ``/var/run/libvirt/libvirt-sock``. This socket is recommended to + be started on boot by default. + +* ``libvirtd-ro.socket`` - the unit file corresponding to the main read-write + UNIX socket ``/var/run/libvirt/libvirt-sock-ro``. This socket is recommended + to be started on boot by default. + +* ``libvirtd-admin.socket`` - the unit file corresponding to the administrative + UNIX socket ``/var/run/libvirt/libvirt-admin-sock``. This socket is + recommended to be started on boot by default. + +* ``libvirtd-tcp.socket`` - the unit file corresponding to the TCP 16509 port + for non-TLS remote access. This socket 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 socket should not be configured to start on boot + until the administrator has deployed x509 certificates and optionally + configured a suitable authentication mechanism. + +The socket unit files are newly introduced in 5.6.0. On newly installed hosts +the UNIX socket units should be enabled by default. When upgrading an existing +host from a previous version of libvirt, the socket unit files will be masked +if libvirtd is currently configured to use the ``--listen`` argument, since the +``--listen`` argument is mutually exclusive with use of socket activation. + +When systemd socket activation is used a number of configuration settings in +``libvirtd.conf`` are no longer honoured. 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. + +Systemd releases prior to version 227 lacked support for passing the activation +socket unit names into the service. When using these old versions, the +``tcp_port``, ``tls_port`` and ``unix_sock_dir`` settings in ``libvirtd.conf`` +must be changed in lock-step with the equivalent settings in the unit files to +ensure that ``libvirtd`` can identify the sockets. + + +Modular driver daemons +====================== + +The modular daemons are named after the driver which they are running, with +the pattern ``virt${DRIVER}d`` and will become the default in future libvirt. +They are configured via the files ``/etc/libvirt/virt${DRIVER}d.conf`` + +The following modular daemons currently exist for hypervisor drivers + +* ``virtqemud`` - the QEMU management daemon, for running virtual machines + on UNIX platforms, optionally with KVM acceleration, in either system or + session mode +* ``virtxend`` - the Xen management daemon, for running virtual machines + on the Xen hypervisor, in system mode only +* ``virtlxcd`` - the Linux Container management daemon, for running LXC guests + in system mode only +* ``virtbhyved`` - the BHyve management daemon, for running virtual machines + on FreeBSD with the BHyve hypervisor, in system mode. +* ``virtvboxd`` - the VirtualBox management daemon, for running virtual machines + on UNIX platforms. + +The additional modular daemons service secondary drivers + +* ``virtinterfaced`` - the host NIC management daemon, in system mode only +* ``virtnetworkd`` - the virtual network management daemon, in system mode only +* ``virtnodedevd`` - the host physical device management daemon, in system mode + only +* ``virtnwfilterd`` - the host firewall management daemon, in system mode only +* ``virtsecretd`` - the host secret management daemon, in system or session mode +* ``virtstoraged`` - the host storage management daemon, in system or session + mode + + +Modular Sockets +--------------- + +When running in system mode, ``virt${DRIVER}d`` exposes three UNIX domain +sockets: + +* ``/var/run/libvirt/virt${DRIVER}d-sock`` - the primary socket for accessing + libvirt APIs, with full read-write privileges. For many of the daemons, a + connection to this socket gives the client privileges that are equivalent to + having a root shell. This is the socket that most management applications + connect to by default. + +* ``/var/run/libvirt/virt${DRIVER}d-sock-ro`` - the secondary socket for + accessing libvirt APIs, with limited read-only privileges. A connection to + this socket gives the ability to query the existance of objects and monitor + some aspects of their operation. This is the socket that most management + applications connect to when requesting read only mode. Typically this is + what a monitoring app would use. + +* ``/var/run/libvirt/virt${DRIVER}d-admin-sock`` - the administrative socket for + controlling operation of the daemon itself (as opposed to drivers it is + running). This can be used to dynamically reconfigure some aspects of the + daemon and monitor/control connected clients. + +NB, some distros will use ``/run`` instead of ``/var/run``. + +When running in session mode, ``virt${DRIVER}d`` exposes two UNIX domain sockets + +* ``$XDG_RUNTIME_DIR/libvirt/virt${DRIVER}d-sock`` - the primary socket for + accessing libvirt APIs, with full read-write privileges. A connection to this + socket does not alter the privileges that the client already has. This is the + socket that most management applications connect to by default. + +* ``$XDG_RUNTIME_DIR/libvirt/virt${DRIVER}d-admin-sock`` - the administrative + socket for controlling operation of the daemon itself (as opposed to drivers + it is running). This can be used to dynamically reconfigure some aspects of + the daemon and monitor/control connected clients. + +Notice that the session mode does not have a separate read-only socket. Since +the clients must be running as the same user as the daemon itself, there is +not any security benefit from attempting to enforce a read-only mode. + +``$XDG_RUNTIME_DIR`` commonly points to a per-user private location on tmpfs, +such as ``/run/user/$UID``. + +Modular Systemd Integration +--------------------------- + +When the ``virt${DRIVER}d`` daemon is managed by ``systemd`` a number of +desirable features are available, most notably socket activation. + +Libvirt ships a number of unit files for controlling virt${DRIVER}d + +* ``virt${DRIVER}d.service`` - the main unit file for launching the + ``virt${DRIVER}d daemon`` in system mode. The command line arguments passed + can be configured by editting ``/etc/sysconfig/virt${DRIVER}d``. This is + typically only needed to control the use of the auto shutdown timeout value. + It is recommended that this service unit be configured to start on boot. + This is because various libvirt drivers support autostart of their objects. + If it is known that autostart is not required, this unit can be left to start + on demand. + +* ``virt${DRIVER}d.socket`` - the unit file corresponding to the main read-write + UNIX socket ``/var/run/libvirt/virt${DRIVER}d-sock``. This socket is + recommended to be started on boot by default. + +* ``virt${DRIVER}d-ro.socket`` - the unit file corresponding to the main + read-write UNIX socket ``/var/run/libvirt/virt${DRIVER}d-sock-ro``. This + socket is recommended to be started on boot by default. + +* ``virt${DRIVER}d-admin.socket`` - the unit file corresponding to the + administrative UNIX socket ``/var/run/libvirt/virt${DRIVER}d-admin-sock``. + This socket is recommended to be started on boot by default. + +The socket unit files are newly introduced in 5.6.0. On newly installed hosts +the UNIX socket units should be enabled by default. When upgrading an existing +host from a previous version of libvirt, the socket unit files will be masked +if virt${DRIVER}d is currently configured to use the ``--listen`` argument, +since the ``--listen`` argument is mutually exclusive with use of socket +activation. + +When systemd socket activation is used a number of configuration settings in +``virt${DRIVER}d.conf`` are no longer honoured. 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 ``virt${DRIVER}d.socket`` and + ``virt${DRIVER}d-ro.socket`` unit files + +* ``unix_sock_ro_perms`` - read-only UNIX socket permissions, controlled via the + ``SocketMode`` parameter in the ``virt${DRIVER}d-ro.socket`` unit file + +* ``unix_sock_rw_perms`` - read-write UNIX socket permissions, controlled via + the ``SocketMode`` parameter in the ``virt${DRIVER}d.socket`` unit file + +* ``unix_sock_admin_perms`` - admin UNIX socket permissions, controlled via the + ``SocketMode`` parameter in the ``virt${DRIVER}d-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 + ``virt${DRIVER}d.socket``, ``virt${DRIVER}d-ro.socket`` and + ``virt${DRIVER}d-admin.socket`` unit files. + +Systemd releases prior to version 227 lacked support for passing the activation +socket unit names into the service. When using these old versions, the +``unix_sock_dir`` setting in ``virt${DRIVER}d.conf`` must be changed in +lock-step with the equivalent setting in the unit files to ensure that +``virt${DRIVER}d`` can identify the sockets. + + +Switching to modular daemons +---------------------------- + +If a host is currently set to use the monolithic ``libvirtd`` daemon and needs +to be migrated to the monolithic daemons a number of services need to be +changed. The steps below outline the process on hosts using the systemd init +service. + +While it is technically possible todo this while virtual machines are running, +it is recommended that virtual machines be stopped or live migrated to a new +host first. + +#. Stop the current monolithic daemon and its socket units + + :: + + $ systemctl stop libvirtd.service + $ systemctl stop libvirtd{,-ro,-admin,-tcp,-tls}.socket + +#. Disable future start of the monolithic daemon + + :: + + $ systemctl disable libvirtd.service + $ systemctl disable libvirtd{,-ro,-admin,-tcp,-tls}.socket + + For stronger protection it is valid to use ``mask`` instead of ``disable`` + too. + +#. Enable the new daemons for the particular virtualizationd driver desired, + and any of the secondary drivers to accompany it. The following example + enables the QEMU driver and all the secondary drivers: + + :: + + $ for drv in qemu interface network nodedev nwfilter secret storage + do + systemctl unmask virt${drv}d.service + systemctl unmask virt${drv}d{,-ro,-admin}.socket + systemctl enable virt${drv}d.service + systemctl enable virt${drv}d{,-ro,-admin}.socket + done + +#. Start the sockets for the same set of daemons. There is no need to start the + services as they will get started when the first socket connection is + established + + :: + + $ for drv in qemu network nodedev nwfilter secret storage + do + systemctl start virt${drv}d{,-ro,-admin}.socket + done + +#. If connections from remote hosts need to be supported the proxy daemon + must be enabled and started + + :: + + $ systemctl unmask virtproxyd.service + $ systemctl unmask virtproxyd{,-ro,-admin}.socket + $ systemctl enable virtproxyd.service + $ systemctl enable virtproxyd{,-ro,-admin}.socket + $ systemctl start virtproxyd{,-ro,-admin}.socket + + The UNIX sockets allow for remote access using SSH tunneling. If ``libvirtd`` + had TCP or TLS sockets configured, those should be started too + + :: + + $ systemctl unmask virtproxyd-tls.socket + $ systemctl enable virtproxyd-tls.socket + $ systemctl start virtproxyd-tls.socket + + +Proxy daemon +============ + +The monolithic daemon is known as ``libvirtd`` and has historically been the +default in libvirt. It is configured via the file ``/etc/libvirt/libvirtd.conf`` + + +Proxy sockets +------------- + +When running in system mode, ``virtproxyd`` exposes three UNIX domain sockets, +and optionally, one or two TCP sockets. These sockets are identical to those +provided by the traditional ``libvirtd`` so refer to earlier documentation in +this page. + +When running in session mode, ``virtproxyd`` exposes two UNIX domain sockets, +which are again identical to those provided by ``libvirtd``. + +Proxy Systemd Integration +------------------------- + +When the ``virtproxyd`` daemon is managed by ``systemd`` a number of desirable +features are available, most notably socket activation. + +Libvirt ships a number of unit files for controlling virtproxyd + +* ``virtproxyd.service`` - the main unit file for launching the virtproxyd + daemon in system mode. The command line arguments passed can be configured by + editting ``/etc/sysconfig/virtproxyd``. This is typically only needed to + control the use of the auto shutdown timeout value. + +* ``virtproxyd.socket`` - the unit file corresponding to the main read-write + UNIX socket ``/var/run/libvirt/libvirt-sock``. This socket is recommended to + be started on boot by default. + +* ``virtproxyd-ro.socket`` - the unit file corresponding to the main read-write + UNIX socket ``/var/run/libvirt/libvirt-sock-ro``. This socket is recommended + to be started on boot by default. + +* ``virtproxyd-admin.socket`` - the unit file corresponding to the + administrative UNIX socket ``/var/run/libvirt/libvirt-admin-sock``. This + socket is recommended to be started on boot by default. + +* ``virtproxyd-tcp.socket`` - the unit file corresponding to the TCP 16509 port + for non-TLS remote access. This socket should not be configured to start on + boot until the administrator has configured a suitable authentication + mechanism. + +* ``virtproxyd-tls.socket`` - the unit file corresponding to the TCP 16509 port + for TLS remote access. This socket should not be configured to start on boot + until the administrator has deployed x509 certificates and optionally + configured a suitable authentication mechanism. + +The socket unit files are newly introduced in 5.6.0. On newly installed hosts +the UNIX socket units should be enabled by default. When upgrading an existing +host from a previous version of libvirt, the socket unit files will be masked +if virtproxyd is currently configured to use the ``--listen`` argument, since +the ``--listen`` argument is mutually exclusive with use of socket activation. + +When systemd socket activation is used a number of configuration settings in +``virtproxyd.conf`` are no longer honoured. Instead these settings must be +controlled via the system unit files. Refer to the earlier documentation on +the ``libvirtd`` service socket configuration for further information. + + +Logging daemon +============== + +The ``virtlogd`` daemon provides a service for managing log files associated +with QEMU virtual machines. The QEMU process is given one or more pipes, the +other end of which are owned by the ``virtlogd`` daemon. It will then write +data on those pipes to log files, while enforcing a maximum file size and +performing log rollover at the size limit. + +Since the daemon holds open anoymous pipe file descriptors, it must never be +stopped while any QEMU virtual machines are running. To enable software updates +to be applied, the daemon is capable of re-executing itself while keeping all +file descriptors open. This can be triggered by sending the daemon ``SIGUSR1`` + +Logging Sockets +--------------- + +When running in system mode, ``virtlogd`` exposes two UNIX domain sockets: + +* ``/var/run/libvirt/virtlogd-sock`` - the primary socket for accessing + libvirt APIs, with full read-write privileges. Access to the socket is + restricted to the root user. + +* ``/var/run/libvirt/virtlogd-admin-sock`` - the administrative socket for + controlling operation of the daemon itself (as opposed to drivers it is + running). This can be used to dynamically reconfigure some aspects of the + daemon and monitor/control connected clients. + +NB, some distros will use ``/run`` instead of ``/var/run``. + +When running in session mode, ``virtlogd`` exposes two UNIX domain sockets + +* ``$XDG_RUNTIME_DIR/libvirt/virtlogd-sock`` - the primary socket for + accessing libvirt APIs, with full read-write privileges. Access to the + socket is restricted to the unprivileged user running the daemon. + +* ``$XDG_RUNTIME_DIR/libvirt/virtlogd-admin-sock`` - the administrative + socket for controlling operation of the daemon itself (as opposed to drivers + it is running). This can be used to dynamically reconfigure some aspects of + the daemon and monitor/control connected clients. + +``$XDG_RUNTIME_DIR`` commonly points to a per-user private location on tmpfs, +such as ``/run/user/$UID``. + +Logging Systemd Integration +--------------------------- + +When the ``virtlogd`` daemon is managed by ``systemd`` a number of desirable +features are available, most notably socket activation. + +Libvirt ships a number of unit files for controlling virtlogd + +* ``virtlogd.service`` - the main unit file for launching the + ``virtlogd daemon`` in system mode. The command line arguments passed + can be configured by editting ``/etc/sysconfig/virtlogd``. This is + typically only needed to control the use of the auto shutdown timeout value. + +* ``virtlogd.socket`` - the unit file corresponding to the main read-write + UNIX socket ``/var/run/libvirt/virtlogd-sock``. This socket is recommended + to be started on boot by default. + +* ``virtlogd-admin.socket`` - the unit file corresponding to the administrative + UNIX socket ``/var/run/libvirt/virtlogd-admin-sock``. This socket is + recommended to be started on boot by default. + +When systemd socket activation is used a number of configuration settings in +``virtlogd.conf`` are no longer honoured. 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 ``virtlogd.socket`` and + ``virtlogd-ro.socket`` unit files + +* ``unix_sock_ro_perms`` - read-only UNIX socket permissions, controlled via the + ``SocketMode`` parameter in the ``virtlogd-ro.socket`` unit file + +* ``unix_sock_rw_perms`` - read-write UNIX socket permissions, controlled via + the ``SocketMode`` parameter in the ``virtlogd.socket`` unit file + +* ``unix_sock_admin_perms`` - admin UNIX socket permissions, controlled via the + ``SocketMode`` parameter in the ``virtlogd-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 + ``virtlogd.socket`` and ``virtlogd-admin.socket`` unit files. + +Systemd releases prior to version 227 lacked support for passing the activation +socket unit names into the service. When using these old versions, the +``unix_sock_dir`` setting in ``virtlogd.conf`` must be changed in +lock-step with the equivalent setting in the unit files to ensure that +``virtlogd`` can identify the sockets. + +Locking daemon +============== + +The ``virtlockd`` daemon provides a service for holding locks against file +images and devices serving as backing storage for virtual disks. The locks +will be held for as long as there is a QEMU process running with the disk +open. + +To ensure continuity of locking, the daemon holds open anoymous file +descriptors, it must never be stopped while any QEMU virtual machines are +running. To enable software updates to be applied, the daemon is capable of +re-executing itself while keeping all file descriptors open. This can be +triggered by sending the daemon ``SIGUSR1`` + +Locking Sockets +--------------- + +When running in system mode, ``virtlockd`` exposes two UNIX domain sockets: + +* ``/var/run/libvirt/virtlockd-sock`` - the primary socket for accessing + libvirt APIs, with full read-write privileges. Access to the socket is + restricted to the root user. + +* ``/var/run/libvirt/virtlockd-admin-sock`` - the administrative socket for + controlling operation of the daemon itself (as opposed to drivers it is + running). This can be used to dynamically reconfigure some aspects of the + daemon and monitor/control connected clients. + +NB, some distros will use ``/run`` instead of ``/var/run``. + +When running in session mode, ``virtlockd`` exposes two UNIX domain sockets + +* ``$XDG_RUNTIME_DIR/libvirt/virtlockd-sock`` - the primary socket for + accessing libvirt APIs, with full read-write privileges. Access to the + socket is restricted to the unprivileged user running the daemon. + +* ``$XDG_RUNTIME_DIR/libvirt/virtlockd-admin-sock`` - the administrative + socket for controlling operation of the daemon itself (as opposed to drivers + it is running). This can be used to dynamically reconfigure some aspects of + the daemon and monitor/control connected clients. + +``$XDG_RUNTIME_DIR`` commonly points to a per-user private location on tmpfs, +such as ``/run/user/$UID``. + +Locking Systemd Integration +--------------------------- + +When the ``virtlockd`` daemon is managed by ``systemd`` a number of desirable +features are available, most notably socket activation. + +Libvirt ships a number of unit files for controlling virtlockd + +* ``virtlockd.service`` - the main unit file for launching the + ``virtlockd daemon`` in system mode. The command line arguments passed + can be configured by editting ``/etc/sysconfig/virtlockd``. This is + typically only needed to control the use of the auto shutdown timeout value. + +* ``virtlockd.socket`` - the unit file corresponding to the main read-write + UNIX socket ``/var/run/libvirt/virtlockd-sock``. This socket is recommended + to be started on boot by default. + +* ``virtlockd-admin.socket`` - the unit file corresponding to the administrative + UNIX socket ``/var/run/libvirt/virtlockd-admin-sock``. This socket is + recommended to be started on boot by default. + +When systemd socket activation is used a number of configuration settings in +``virtlockd.conf`` are no longer honoured. 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 ``virtlockd.socket`` and + ``virtlockd-ro.socket`` unit files + +* ``unix_sock_ro_perms`` - read-only UNIX socket permissions, controlled via the + ``SocketMode`` parameter in the ``virtlockd-ro.socket`` unit file + +* ``unix_sock_rw_perms`` - read-write UNIX socket permissions, controlled via + the ``SocketMode`` parameter in the ``virtlockd.socket`` unit file + +* ``unix_sock_admin_perms`` - admin UNIX socket permissions, controlled via the + ``SocketMode`` parameter in the ``virtlockd-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 + ``virtlockd.socket`` and ``virtlockd-admin.socket`` unit files. + +Systemd releases prior to version 227 lacked support for passing the activation +socket unit names into the service. When using these old versions, the +``unix_sock_dir`` setting in ``virtlockd.conf`` must be changed in +lock-step with the equivalent setting in the unit files to ensure that +``virtlockd`` can identify the sockets. diff --git a/docs/docs.html.in b/docs/docs.html.in index 004f099a9f..142c79bfa9 100644 --- a/docs/docs.html.in +++ b/docs/docs.html.in @@ -18,6 +18,9 @@ <dt><a href="migration.html">Migration</a></dt> <dd>Migrating guests between machines</dd> + <dt><a href="daemons.html">Daemons</a></dt> + <dd>Overview of the daemons provided by libvirt</dd> + <dt><a href="remote.html">Remote access</a></dt> <dd>Enable remote access over TCP</dd> -- 2.24.1

4 years, 2 months

3
6
0 / 0

[PATCH 0/2] qemu_shim: Two simple fixes

by Michal Privoznik

Actually, 2/2 suggests we need to tweak SELinux policy too. Should I file a bug? Michal Prívozník (2): qemu_shim: Allow other users to enter the root dir qemu_shim: Ignore SIGPIPE src/qemu/qemu_shim.c | 7 +++++++ 1 file changed, 7 insertions(+) -- 2.24.1

4 years, 2 months

3
6
0 / 0

[libvirt PATCH 0/6] Introduce Local Migration Support in Libvirt

by Daniel P. Berrangé

I'm (re-)sending this patch series on behalf of Shaju Abraham <shaju.abraham(a)nutanix.com> who has tried to send this several times already. Red Hat's email infrastructure is broken, accepting the mails and then failing to deliver them to mailman, or any other Red Hat address. Unfortunately it means that while we can send comments back to Shaju on this thread, subscribers will then probably fail to see any responses Shaju tries to give :-( To say this is bad is an understatement. I have yet another ticket open tracking & escalating this awful problem but can't give any ETA on a fix :-( Anyway, with that out of the way, here's Shaju's original cover letter below.... 1) What is this patch series about? Local live migration of a VM is about Live migrating a VM instance with in the same node. Traditional libvirt live migration involves migrating the VM from a source node to a remote node. The local migrations are forbidden in Libvirt for a myriad of reasons. This patch series is to enable local migration in Libvirt. 2) Why Local Migration is important? The ability to Live migrate a VM locally paves the way for hypervisor upgrades without shutting down the VM. For example to upgrade qemu after a security upgrade, we can locally migrate the VM to the new qemu instance. By utilising capabilities like "bypass-shared-memory" in qemu, the hypervisor upgrades are faster. 3) Why is local migration difficult in Libvirt? Libvirt always assumes that the name/UUID pair is unique with in a node. During local migration there will be two different VMs with the same UUID/name pair which will confuse the management stack. There are other path variables like monitor path, config paths etc which assumes that the name/UUID pair is unique. So during migration the same monitor will be used by both the source and the target. We cannot assign a temporary UUID to the target VM, since UUID is a part of the machine ABI which is immutable. To decouple the dependecy on UUID/name, a new field (the domain id) is included in all the PATHs that Libvirt uses. This will ensure that all instances of the VM gets a unique PATH. 4) How is the Local Migration Designed ? Libvirt manages all the VM domain objects using two hash tables which are indexed using either the UUID or Name.During the Live migration the domain entry in the source node gets deleted and a new entry gets populated in the target node, which are indexed using the same name/UUID.But for the Local migration, there is no remote node. Both the source and the target nodes are same. So inorder to model the remote node, two more hashtables are introduced which represents the hash tables of the remote node during migration. The Libvirt migration involves 5 stages 1) Begin 2) Prepare 3) Perform 4) Finish 5) Confirm Begin,Perform and Confirm gets executed on the source node where as Prepare and Finish gets executed on the target node. In the case of Local Migration Perform and Finish stages uses the newly introduced 'remote hash table' and rest of the stages uses the 'source hash tables'. Once the migration is completed, that is after the confirm phase, the VM domain object is moved from the 'remote hash table' to the 'source hash table'. This is required so that other Libvirt commands like 'virsh list' can display all the VMs running in the node. 5) How to test Local Migration? A new flag 'local' is added to the 'virsh migrate' command to enable local migration. The syntax is virsh migrate --live --local 'domain-id' qemu+ssh://ip-address/system 6) What are the known issues? SeLinux policies is know to have issues with the creating /dev/hugepages entries during VM launch. In order to test local migration disable SeLinux using 'setenforce 0'. Shaju Abraham (6): Add VIR_MIGRATE_LOCAL flag to virsh migrate command Introduce remote hash tables and helper routines Add local migration support in QEMU Migration framework Modify close callback routines to handle local migration Make PATHs unique for a VM object instance Move the domain object from remote to source hash table include/libvirt/libvirt-domain.h | 6 + src/conf/virdomainobjlist.c | 232 +++++++++++++++++++++++++++++-- src/conf/virdomainobjlist.h | 10 ++ src/libvirt_private.syms | 4 + src/qemu/qemu_conf.c | 4 +- src/qemu/qemu_domain.c | 28 +++- src/qemu/qemu_domain.h | 2 + src/qemu/qemu_driver.c | 46 +++++- src/qemu/qemu_migration.c | 59 +++++--- src/qemu/qemu_migration.h | 5 + src/qemu/qemu_migration_cookie.c | 121 ++++++++-------- src/qemu/qemu_migration_cookie.h | 2 + src/qemu/qemu_process.c | 3 +- src/qemu/qemu_process.h | 2 + src/util/virclosecallbacks.c | 48 +++++-- src/util/virclosecallbacks.h | 3 + tools/virsh-domain.c | 7 + 17 files changed, 471 insertions(+), 111 deletions(-) -- 2.24.1

4 years, 2 months

6
18
0 / 0

Entering freeze for libvirt 6.1.0

by Daniel Veillard

As suggested yesterday, I just tagged RC1 in git and pushed signed tarball and source rpm to the usual place: https://libvirt.org/sources/ Seems to work fine in my limited testing, CI is green (amazing !) https://ci.centos.org/view/libvirt/ so looks fine so far, please give it some testing, planning RC2 on Friday with a possible delivery next Monday, thanks, Daniel -- Daniel Veillard | Red Hat Developers Tools http://developer.redhat.com/ veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/

4 years, 2 months

2
3
0 / 0

[libvirt PATCH 0/3] gitdm: Fixes and updates

by Andrea Bolognani

blurb.com *** BLURB HERE ***, Inc. Andrea Bolognani (3): gitdm: Add entry for example.com gitdm: Fix sorting gitdm: Add missing entries docs/gitdm/companies/others | 5 ++++- docs/gitdm/groups/unaffiliated | 5 +++++ 2 files changed, 9 insertions(+), 1 deletion(-) -- 2.24.1

4 years, 2 months

2
4
0 / 0

[PATCH] admin: use g_autofree

by Gaurav Agrawal

From: GAURAV AGRAWAL <agrawalgaurav(a)gnome.org> Signed-off-by: Gaurav Agrawal <agrawalgaurav(a)gnome.org> --- src/admin/libvirt-admin.c | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/src/admin/libvirt-admin.c b/src/admin/libvirt-admin.c index 4099a54854..d841a15f95 100644 --- a/src/admin/libvirt-admin.c +++ b/src/admin/libvirt-admin.c @@ -111,7 +111,7 @@ getSocketPath(virURIPtr uri) virURIParamPtr param = &uri->params[i]; if (STREQ(param->name, "socket")) { - VIR_FREE(sock_path); + g_free(sock_path); sock_path = g_strdup(param->value); } else { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, @@ -203,11 +203,11 @@ virAdmGetDefaultURI(virConfPtr conf, char **uristr) virAdmConnectPtr virAdmConnectOpen(const char *name, unsigned int flags) { - char *sock_path = NULL; + g_autofree char *sock_path = NULL; char *alias = NULL; virAdmConnectPtr conn = NULL; g_autoptr(virConf) conf = NULL; - char *uristr = NULL; + g_autofree char *uristr = NULL; if (virAdmInitialize() < 0) goto error; @@ -233,7 +233,7 @@ virAdmConnectOpen(const char *name, unsigned int flags) goto error; if (alias) { - VIR_FREE(uristr); + g_free(uristr); uristr = alias; } @@ -251,14 +251,11 @@ virAdmConnectOpen(const char *name, unsigned int flags) if (remoteAdminConnectOpen(conn, flags) < 0) goto error; - cleanup: - VIR_FREE(sock_path); - VIR_FREE(uristr); +cleanup: return conn; error: virDispatchError(NULL); - virObjectUnref(conn); conn = NULL; goto cleanup; } -- 2.24.1

4 years, 2 months

2
1
0 / 0

[libvirt PATCH] news: Update for libvirt 6.1.0

by Andrea Bolognani

Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- I probably won't be able to check my computer between now and the release, so if anyone gets a chance to review the patch in the meantime please feel free to push it as well :) docs/news.xml | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) diff --git a/docs/news.xml b/docs/news.xml index cdcf450b48..af157887d3 100644 --- a/docs/news.xml +++ b/docs/news.xml @@ -124,6 +124,15 @@ subelement. </description> </change> + <change> + <summary> + qemu: Introduce the 'tpm-spapr' TPM model + </summary> + <description> + This device, available starting from QEMU 5.0, is limited to + pSeries guests. + </description> + </change> </section> <section title="Improvements"> <change> @@ -138,8 +147,35 @@ to rectify the problem. </description> </change> + <change> + <summary> + qemu: Support "dies" in CPU topology + </summary> + <description> + This CPU topology concept, new in QEMU 4.1.0, sits between the + existing "socket" and "core". + </description> + </change> + <change> + <summary> + libxl: Add support for Credit2 scheduler parameters + </summary> + </change> + <change> + <summary> + lxc: Add support LXC 3 network configuration format + </summary> + </change> </section> <section title="Bug fixes"> + <change> + <summary> + conf: Do not generate machine names ending with a dash + </summary> + <description> + Recent systemd version do not allow them. + </description> + </change> </section> <section title="Packaging changes"> <change> -- 2.24.1

4 years, 2 months

2
1
0 / 0

[libvirt] [PATCH 0/8] Second take on slirp-helper & dbus-vmstate

by marcandre.lureau＠redhat.com

From: Marc-André Lureau <marcandre.lureau(a)redhat.com> Hi, The series "[libvirt] [PATCH v2 00/23] Use a slirp helper process" has been merged and partially reverted. Meanwhile, qemu dbus-vmstate design has been changed and merged upstream. This new series fixes the slirp-helper support. The significant change is that dbus-vmstate now requires a bus (instead of the earlier peer-to-peer connection). The current series doesn't attempt to enforce strict policies on the bus. As long as you can connect to the bus, you can send/receive from/to anyone. A follow-up series should implement the recommendations from https://qemu.readthedocs.io/en/latest/interop/dbus.html#security. The libslirp-rs slirp-helper hasn't yet received an official release. For testing, you may: $ cargo install --features=all --git https://gitlab.freedesktop.org/slirp/libslirp-rs The resulting binary should be ~/.cargo/bin/slirp-helper, so qemu.conf slirp_helper location should be adjusted. With that in place, a VM with user networking (slirp) should now start with the helper process. thanks Marc-André Lureau (8): qemu: remove dbus-vmstate code qemu-conf: add configurable dbus-daemon location qemu-conf: add dbusStateDir qemu: add a DBus daemon helper unit domain: save/restore the state of dbus-daemon running qemu: prepare and stop the dbus daemon qemu: add dbus-vmstate helper migration support qemu-slirp: register helper for migration m4/virt-driver-qemu.m4 | 6 + src/qemu/Makefile.inc.am | 6 +- src/qemu/libvirtd_qemu.aug | 1 + src/qemu/qemu.conf | 3 + src/qemu/qemu_alias.c | 17 +- src/qemu/qemu_alias.h | 3 +- src/qemu/qemu_command.c | 65 +++---- src/qemu/qemu_command.h | 6 +- src/qemu/qemu_conf.c | 9 + src/qemu/qemu_conf.h | 2 + src/qemu/qemu_dbus.c | 283 +++++++++++++++++++++++++---- src/qemu/qemu_dbus.h | 30 +-- src/qemu/qemu_domain.c | 30 +-- src/qemu/qemu_domain.h | 9 +- src/qemu/qemu_extdevice.c | 4 +- src/qemu/qemu_hotplug.c | 165 +++++++++-------- src/qemu/qemu_hotplug.h | 17 +- src/qemu/qemu_migration.c | 57 +++++- src/qemu/qemu_monitor.c | 21 +++ src/qemu/qemu_monitor.h | 3 + src/qemu/qemu_monitor_json.c | 15 ++ src/qemu/qemu_monitor_json.h | 5 + src/qemu/qemu_process.c | 6 + src/qemu/qemu_slirp.c | 126 ++----------- src/qemu/qemu_slirp.h | 4 +- src/qemu/test_libvirtd_qemu.aug.in | 1 + tests/Makefile.am | 1 + 27 files changed, 564 insertions(+), 331 deletions(-) -- 2.25.0.rc2.1.g09a9a1a997

4 years, 2 months

6
31
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Devel February 2020