External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-07-12 12:55:46 +00:00
Code Issues Packages Projects Releases Wiki Activity
9ec0e28e87
libvirt/docs/manpages/virtxend.rst

199 lines
4.5 KiB
ReStructuredText
Raw Normal View History

docs: add manpage for virtxend 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 14:08:37 +00:00
========
virtxend
========
-----------------------------
libvirt Xen management daemon
-----------------------------
:Manual section: 8
:Manual group: Virtualization Support
.. contents::
SYNOPSIS
========
``virtxend`` [*OPTION*]...
DESCRIPTION
===========
The ``virtxend`` 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 Xen virtual
machines.
The ``virtxend`` 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 08:58:18 +00: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 virtxend 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 14:08:37 +00:00
Restarting ``virtxend`` 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 12:15:38 +00:00
DAEMON STARTUP MODES
====================
docs: add manpage for virtxend 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 14:08:37 +00:00
The ``virtxend`` 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 12:15:38 +00:00
Socket activation mode
----------------------
docs: add manpage for virtxend 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 14:08:37 +00: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 12:15:38 +00: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/virtxend.conf`` will no longer have any effect.
docs: add manpage for virtxend 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 14:08:37 +00: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 06:29:53 +00: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 12:15:38 +00: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 06:29:53 +00: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 12:15:38 +00: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 06:29:53 +00:00
docs: add manpage for virtxend 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 14:08:37 +00: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`` ``virtxend`` will reload its configuration.
FILES
=====
manpages: Remove reference to a session daemon for libxl The libxl driver has no session daemon therefore its split daemon (virtxend) has to be ran as root. Any attempt to start it with euid != 0 fails. This is why the daemon does not look under any of XDG_* paths either. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-03-08 16:55:00 +00:00
The ``virtxend`` program must be ran as root. Trying to start the program under
a different user results in error.
docs: add manpage for virtxend 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 14:08:37 +00:00
* ``@SYSCONFDIR@/libvirt/virtxend.conf``
The default configuration file used by ``virtxend``, unless overridden on the
command line using the ``-f`` | ``--config`` option.
docs: Document libxl.conf location This is similar to my earlier commit which documented lxc.conf location. Just like LXC, the libxl driver has only the system connection and thus only few places need changing. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-03-08 17:02:08 +00:00
In addition to the default configuration file, ``virtxend`` reads
configuration for the libxl driver from:
* ``@SYSCONFDIR@/libvirt/libxl.conf``
This file contains various knobs and default values for virtual machines
created within libxl driver, and offers a way to override the built in
defaults, Location of this file can't be overridden by any command line switch.
docs: add manpage for virtxend 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 14:08:37 +00:00
* ``@RUNSTATEDIR@/libvirt/virtxend-sock``
* ``@RUNSTATEDIR@/libvirt/virtxend-sock-ro``
* ``@RUNSTATEDIR@/libvirt/virtxend-admin-sock``
The sockets ``virtxend`` will use.
The TLS **Server** private key ``virtxend`` will use.
* ``@RUNSTATEDIR@/virtxend.pid``
The PID file to use, unless overridden by the ``-p`` | ``--pid-file`` option.
EXAMPLES
========
To retrieve the version of ``virtxend``:
::
# virtxend --version
virtxend (libvirt) @VERSION@
To start ``virtxend``, instructing it to daemonize and create a PID file:
::
# virtxend -d
# ls -la @RUNSTATEDIR@/virtxend.pid
-rw-r--r-- 1 root root 6 Jul 9 02:40 @RUNSTATEDIR@/virtxend.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
=======
``virtxend`` 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 14:39:22 +00:00
`https://libvirt.org/daemons.html <https://libvirt.org/daemons.html>`_,
`https://libvirt.org/drvxen.html <https://libvirt.org/drvxen.html>`_
Reference in New Issue Copy Permalink