shaba/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-12-23 21:34:54 +03:00
Code Releases Activity
da3b0468f3
libvirt/docs/manpages/virtqemud.rst

237 lines
5.8 KiB
ReStructuredText
Raw Normal View History

docs: add manpage for virtqemud This is an adaptation of the libvirtd manpage. Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-09-24 17:08:37 +03:00
=========
virtqemud
=========
------------------------------
libvirt QEMU management daemon
------------------------------
:Manual section: 8
:Manual group: Virtualization Support
.. contents::
SYNOPSIS
========
``virtqemud`` [*OPTION*]...
DESCRIPTION
===========
The ``virtqemud`` program is a server side daemon component of the libvirt
virtualization management system.
It is one of a collection of modular daemons that replace functionality
previously provided by the monolithic ``libvirtd`` daemon.
This daemon runs on virtualization hosts to provide management for QEMU virtual
machines.
The ``virtqemud`` daemon only listens for requests on a local Unix domain
docs: manpages: Clarify that only TLS/TCP remote access needs 'virtproxyd' Spell out that TCP and TLS needs virtproxyd as 'off-host' might mean that also ssh transport requires it. Also fix the name of the 'virtproxyd' daemon. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-04-20 11:58:18 +03:00
socket. Remote access via TLS/TCP and backwards compatibility with legacy
clients expecting ``libvirtd`` is provided by the ``virtproxyd`` daemon.
docs: add manpage for virtqemud This is an adaptation of the libvirtd manpage. Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-09-24 17:08:37 +03:00
Restarting ``virtqemud`` does not interrupt running guests. Guests continue to
operate and changes in their state will generally be picked up automatically
during startup. None the less it is recommended to avoid restarting with
running guests whenever practical.
docs: Do not support non-socket activated modular daemons with systemd Due to the setup of the modular daemon service files the reverting to non-socket activated daemons could have never worked. The reason is that masking the socket files prevents starting the daemons since they require (as in Requires= rather than Wants= in the service file) the sockets. On top of that it creates issues with some libvirt-guests setups and needlessly increases our support matrix. Nothing prevents users to modify their setup in a way that will still work without socket activation, but supporting such setup only creates burden on our part. This technically reverts most of commit 59d30adacd1d except the change made to the libvirtd manpage since the monolithic daemon still supports traditional mode of starting even on systemd. Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2022-10-18 15:15:38 +03:00
DAEMON STARTUP MODES
====================
docs: add manpage for virtqemud This is an adaptation of the libvirtd manpage. Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-09-24 17:08:37 +03:00
The ``virtqemud`` daemon is capable of starting in two modes.
docs: Do not support non-socket activated modular daemons with systemd Due to the setup of the modular daemon service files the reverting to non-socket activated daemons could have never worked. The reason is that masking the socket files prevents starting the daemons since they require (as in Requires= rather than Wants= in the service file) the sockets. On top of that it creates issues with some libvirt-guests setups and needlessly increases our support matrix. Nothing prevents users to modify their setup in a way that will still work without socket activation, but supporting such setup only creates burden on our part. This technically reverts most of commit 59d30adacd1d except the change made to the libvirtd manpage since the monolithic daemon still supports traditional mode of starting even on systemd. Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2022-10-18 15:15:38 +03:00
Socket activation mode
----------------------
docs: add manpage for virtqemud This is an adaptation of the libvirtd manpage. Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-09-24 17:08:37 +03:00
docs: Do not support non-socket activated modular daemons with systemd Due to the setup of the modular daemon service files the reverting to non-socket activated daemons could have never worked. The reason is that masking the socket files prevents starting the daemons since they require (as in Requires= rather than Wants= in the service file) the sockets. On top of that it creates issues with some libvirt-guests setups and needlessly increases our support matrix. Nothing prevents users to modify their setup in a way that will still work without socket activation, but supporting such setup only creates burden on our part. This technically reverts most of commit 59d30adacd1d except the change made to the libvirtd manpage since the monolithic daemon still supports traditional mode of starting even on systemd. Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2022-10-18 15:15:38 +03:00
On hosts with systemd it is started in socket activation mode and it will rely
on systemd to create and listen on the UNIX sockets and pass them as pre-opened
file descriptors. In this mode most of the socket related config options in
``/etc/libvirt/virtqemud.conf`` will no longer have any effect.
docs: add manpage for virtqemud This is an adaptation of the libvirtd manpage. Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-09-24 17:08:37 +03:00
libvirt-guests: Fix dependency ordering in service file After some debugging and discussion with systemd team it turns out we are misusing the ordering in libvirt-guests.service. That happened because we want to support both monolithic and modular daemon setups and on top of that we also want to support socket activation and services without socket activation. Unfortunately this is impossible to express in the unit file because of how transactions are handled in systemd when dependencies are resolved and multiple actions (jobs) are queued. For explanation from Michal Sekletar see comment #7 in the BZ this patch is fixing: https://bugzilla.redhat.com/show_bug.cgi?id=1964855#c7 In order to support all the scenarios this patch also amends the manpages so that users that are changing the default can also read how to correct the dependency ordering in libvirt-guests unit file. Ideally we would also keep the existing configuration during upgrade, but due to our huge support matrix this seems hardly feasible as it could introduce even more problems. Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2022-08-30 09:29:53 +03:00
docs: Do not support non-socket activated modular daemons with systemd Due to the setup of the modular daemon service files the reverting to non-socket activated daemons could have never worked. The reason is that masking the socket files prevents starting the daemons since they require (as in Requires= rather than Wants= in the service file) the sockets. On top of that it creates issues with some libvirt-guests setups and needlessly increases our support matrix. Nothing prevents users to modify their setup in a way that will still work without socket activation, but supporting such setup only creates burden on our part. This technically reverts most of commit 59d30adacd1d except the change made to the libvirtd manpage since the monolithic daemon still supports traditional mode of starting even on systemd. Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2022-10-18 15:15:38 +03:00
Traditional service mode
------------------------
libvirt-guests: Fix dependency ordering in service file After some debugging and discussion with systemd team it turns out we are misusing the ordering in libvirt-guests.service. That happened because we want to support both monolithic and modular daemon setups and on top of that we also want to support socket activation and services without socket activation. Unfortunately this is impossible to express in the unit file because of how transactions are handled in systemd when dependencies are resolved and multiple actions (jobs) are queued. For explanation from Michal Sekletar see comment #7 in the BZ this patch is fixing: https://bugzilla.redhat.com/show_bug.cgi?id=1964855#c7 In order to support all the scenarios this patch also amends the manpages so that users that are changing the default can also read how to correct the dependency ordering in libvirt-guests unit file. Ideally we would also keep the existing configuration during upgrade, but due to our huge support matrix this seems hardly feasible as it could introduce even more problems. Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2022-08-30 09:29:53 +03:00
docs: Do not support non-socket activated modular daemons with systemd Due to the setup of the modular daemon service files the reverting to non-socket activated daemons could have never worked. The reason is that masking the socket files prevents starting the daemons since they require (as in Requires= rather than Wants= in the service file) the sockets. On top of that it creates issues with some libvirt-guests setups and needlessly increases our support matrix. Nothing prevents users to modify their setup in a way that will still work without socket activation, but supporting such setup only creates burden on our part. This technically reverts most of commit 59d30adacd1d except the change made to the libvirtd manpage since the monolithic daemon still supports traditional mode of starting even on systemd. Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2022-10-18 15:15:38 +03:00
On hosts without systemd, it will create and listen on UNIX sockets itself.
libvirt-guests: Fix dependency ordering in service file After some debugging and discussion with systemd team it turns out we are misusing the ordering in libvirt-guests.service. That happened because we want to support both monolithic and modular daemon setups and on top of that we also want to support socket activation and services without socket activation. Unfortunately this is impossible to express in the unit file because of how transactions are handled in systemd when dependencies are resolved and multiple actions (jobs) are queued. For explanation from Michal Sekletar see comment #7 in the BZ this patch is fixing: https://bugzilla.redhat.com/show_bug.cgi?id=1964855#c7 In order to support all the scenarios this patch also amends the manpages so that users that are changing the default can also read how to correct the dependency ordering in libvirt-guests unit file. Ideally we would also keep the existing configuration during upgrade, but due to our huge support matrix this seems hardly feasible as it could introduce even more problems. Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2022-08-30 09:29:53 +03:00
docs: add manpage for virtqemud This is an adaptation of the libvirtd manpage. Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-09-24 17:08:37 +03:00
OPTIONS
=======
``-h``, ``--help``
Display command line help usage then exit.
``-d``, ``--daemon``
Run as a daemon & write PID file.
``-f``, ``--config *FILE*``
Use this configuration file, overriding the default value.
``-p``, ``--pid-file *FILE*``
Use this name for the PID file, overriding the default value.
``-t``, ``--timeout *SECONDS*``
Exit after timeout period (in seconds), provided there are neither any client
connections nor any running domains.
``-v``, ``--verbose``
Enable output of verbose messages.
``--version``
Display version information then exit.
SIGNALS
=======
On receipt of ``SIGHUP`` ``virtqemud`` will reload its configuration.
FILES
=====
When run as *root*
------------------
* ``@SYSCONFDIR@/libvirt/virtqemud.conf``
The default configuration file used by ``virtqemud``, unless overridden on the
command line using the ``-f`` | ``--config`` option.
docs: Document qemu.conf locations Surprisingly, we never documented the relationship between connection URI and the location of qemu.conf. Users might wonder what qemu.conf is loaded when they are connecting to the session daemon or embed URI. And what to do if the file doesn't exist for the URI they're using. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-03-04 22:32:29 +03:00
In addition to the default configuration file, ``virtqemud`` reads
docs: Capitalize QEMU driver reference In official docs we refer to it as "QEMU driver", not "qemu driver". Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-03-08 19:14:47 +03:00
configuration for the QEMU driver from:
docs: Document qemu.conf locations Surprisingly, we never documented the relationship between connection URI and the location of qemu.conf. Users might wonder what qemu.conf is loaded when they are connecting to the session daemon or embed URI. And what to do if the file doesn't exist for the URI they're using. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-03-04 22:32:29 +03:00
* ``@SYSCONFDIR@/libvirt/qemu.conf``
This file contains various knobs and default values for virtual machines
created within QEMU driver, and offers a way to override the built in defaults,
for instance (but not limited to): paths to various supplementary binaries, TLS
certificates location, graphical consoles configuration and others. Location of
this file can't be overridden by any command line switch.
docs: add manpage for virtqemud This is an adaptation of the libvirtd manpage. Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-09-24 17:08:37 +03:00
* ``@RUNSTATEDIR@/libvirt/virtqemud-sock``
* ``@RUNSTATEDIR@/libvirt/virtqemud-sock-ro``
* ``@RUNSTATEDIR@/libvirt/virtqemud-admin-sock``
The sockets ``virtqemud`` will use.
The TLS **Server** private key ``virtqemud`` will use.
* ``@RUNSTATEDIR@/virtqemud.pid``
The PID file to use, unless overridden by the ``-p`` | ``--pid-file`` option.
When run as *non-root*
----------------------
* ``$XDG_CONFIG_HOME/libvirt/virtqemud.conf``
The default configuration file used by ``virtqemud``, unless overridden on the
command line using the ``-f``|``--config`` option.
docs: Document qemu.conf locations Surprisingly, we never documented the relationship between connection URI and the location of qemu.conf. Users might wonder what qemu.conf is loaded when they are connecting to the session daemon or embed URI. And what to do if the file doesn't exist for the URI they're using. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-03-04 22:32:29 +03:00
In addition to the default configuration file, ``virtqemud`` reads
configuration for the qemu driver from:
* ``$XDG_CONFIG_HOME/libvirt/qemu.conf``
If the file exists, it can contain various knobs and default values for virtual
machines created within QEMU driver, and offers a way to override the built in
defaults, for instance (but not limited to): paths to various supplementary
binaries, TLS certificates location, graphical consoles configuration and
others. Location of this file can't be overridden by any command line switch.
docs: add manpage for virtqemud This is an adaptation of the libvirtd manpage. Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-09-24 17:08:37 +03:00
* ``$XDG_RUNTIME_DIR/libvirt/virtqemud-sock``
* ``$XDG_RUNTIME_DIR/libvirt/virtqemud-admin-sock``
The sockets ``virtqemud`` will use.
* ``$XDG_RUNTIME_DIR/libvirt/virtqemud.pid``
The PID file to use, unless overridden by the ``-p``|``--pid-file`` option.
If ``$XDG_CONFIG_HOME`` is not set in your environment, ``virtqemud`` will use
``$HOME/.config``
If ``$XDG_RUNTIME_DIR`` is not set in your environment, ``virtqemud`` will use
``$HOME/.cache``
EXAMPLES
========
To retrieve the version of ``virtqemud``:
::
# virtqemud --version
virtqemud (libvirt) @VERSION@
To start ``virtqemud``, instructing it to daemonize and create a PID file:
::
# virtqemud -d
# ls -la @RUNSTATEDIR@/virtqemud.pid
-rw-r--r-- 1 root root 6 Jul 9 02:40 @RUNSTATEDIR@/virtqemud.pid
BUGS
====
Please report all bugs you discover. This should be done via either:
#. the mailing list
`https://libvirt.org/contact.html <https://libvirt.org/contact.html>`_
#. the bug tracker
`https://libvirt.org/bugs.html <https://libvirt.org/bugs.html>`_
Alternatively, you may report bugs to your software distributor / vendor.
AUTHORS
=======
Please refer to the AUTHORS file distributed with libvirt.
COPYRIGHT
=========
Copyright (C) 2006-2020 Red Hat, Inc., and the authors listed in the
libvirt AUTHORS file.
LICENSE
=======
``virtqemud`` is distributed under the terms of the GNU LGPL v2.1+.
This is free software; see the source for copying conditions. There
is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE
SEE ALSO
========
virsh(1), libvirtd(8),
Use 'libvirt.org' instead of 'www.libvirt.org' Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2023-03-14 17:39:22 +03:00
`https://libvirt.org/daemons.html <https://libvirt.org/daemons.html>`_,
`https://libvirt.org/drvqemu.html <https://libvirt.org/drvqemu.html>`_
Copy Permalink