VIRT-ADMIN(1) | Virtualization Support | VIRT-ADMIN(1) |
virt-admin - daemon administration interface
virt-admin [OPTION]... [COMMAND_STRING]
virt-admin [OPTION]... COMMAND [ARG]...
The virt-admin program is the main administration interface for modifying the libvirt daemon configuration at runtime, changing daemon behaviour as well as for monitoring and managing all clients connected to the daemon.
The basic structure of most virt-admin usage is:
virt-admin [OPTION]... <command> [ARG]...
Where command is one of the commands listed below.
The virt-admin program can be used either to run one COMMAND by giving the command and its arguments on the shell command line, or a COMMAND_STRING which is a single shell argument consisting of multiple COMMAND actions and their arguments joined with whitespace, and separated by semicolons between commands. Within COMMAND_STRING, virt-admin understands the same single, double, and backslash escapes as the shell, although you must add another layer of shell escaping in creating the single shell argument. If no command is given in the command line, virt-admin will then start a minimal interpreter waiting for your commands, and the quit command will then exit the program.
The virt-admin program understands the following OPTIONS.
Running virt-admin requires root privileges due to the communications channels used to talk to the daemon. Consider changing the unix_sock_group ownership setting to grant access to specific set of users or modifying unix_sock_rw_perms permissions. Daemon configuration file provides more information about setting permissions.
The following commands are generic.
To display detailed information for a specific command, use its name as the option.
Example
$ virt-admin version Compiled against library: libvirt 1.2.21 Using library: libvirt 1.2.21 Running against daemon: 1.2.20
This command is only available in interactive mode.
To find the currently used URI, check the uri command documented below.
The following commands allow to monitor the daemon's state as well as directly change its internal configuration.
Example
To define a filter which suppresses all e.g. 'virObjectUnref' DEBUG messages, use the following: $ virt-admin daemon-log-filters "4:util.object" (Note the '.' symbol which can be used to more fine-grained filters tailored to specific modules, in contrast, to affect the whole directory containing several modules this would become "4:util"):
Example
To replace the current setting for logging outputs with one that writes to a file while logging errors only, the following could be used: $ virt-admin daemon-log-outputs "4:file:<absolute_path_to_the_file>" To define multiple outputs at once they need to be delimited by spaces: $ virt-admin daemon-log-outputs "4:stderr 2:syslog:<msg_ident>"
The following commands manipulate daemon's server internal configuration. The server is specified by its name.
Background
Each daemon server utilizes a threadpool to accomplish tasks requested by clients connected to it. Every time a client request arrives to the server, it checks whether there is a worker available to accomplish the given task or it should create a new worker for the job (rather than being destroyed, the worker becomes free once the task is finished). Creating new workers, however, is only possible when the current number of workers is still below the configured upper limit.
In addition to these 'standard' workers, a threadpool also
contains a special set of workers called priority workers. Their
purpose is to perform tasks that, unlike tasks carried out by normal
workers, are within libvirt's full control and libvirt guarantees that such
a task cannot hang, thus will always finish. An example of such a task this
would be destroying a domain:
$ virsh destroy <domain>.
Example
# virt-admin server-clients-info libvirtd
nclients_max : 120
nclients : 3
nclients_unauth_max : 20
nclients_unauth : 0
The following commands provide management and monitoring of clients connected to one of daemon's available servers. Clients are specified by their numeric ID which is obtained by listing all clients connected to a specified server (see command client-list).
On the other hand, transport-independent attributes include client's SELinux context (if enabled on the host) and SASL username (if SASL authentication is enabled within daemon).
Examples
# virt-admin client-info libvirtd 1 id : 1 connection_time: 2016-05-03 13:27:04+0200 transport : unix readonly : yes unix_user_id : 0 unix_user_name : root unix_group_id : 0 unix_group_name: root unix_process_id: 10201 # virt-admin client-info libvirtd 2 id : 2 connection_time: 2016-05-03 13:30:33+0200 transport : tcp readonly : no sock_addr : 127.0.0.1:57060
The following environment variables can be set to alter the behaviour of "virt-admin"
DEBUG - Messages at ALL levels get logged
INFO - Logs messages at levels INFO, NOTICE, WARNING and ERROR
NOTICE - Logs messages at levels NOTICE, WARNING and ERROR
WARNING - Logs messages at levels WARNING and ERROR
ERROR - Messages at only ERROR level gets logged.
Messages at level DEBUG or above
Messages at level INFO or above
Messages at level WARNING or above
Messages at level ERROR or above
For further information about debugging options consult <https://libvirt.org/logging.html>
Report any bugs discovered to the libvirt community via the mailing list <https://libvirt.org/contact.html> or bug tracker <https://libvirt.org/bugs.html>. Alternatively report bugs to your software distributor / vendor.
Please refer to the AUTHORS file distributed with libvirt. Based on the virsh man page.
Copyright (C) 2015 Red Hat, Inc., and the authors listed in the libvirt AUTHORS file.
virt-admin is distributed under the terms of the GNU LGPL v2+. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE
virsh(1), virt-xml-validate(1), virt-host-validate(1), <https://libvirt.org/>
2017-10-30 | libvirt-3.9.0 |