neulab/tldr huggingface dataset:
inject-nmi domain
Inject NMI to the guest.
list Syntax:
list [--inactive | --all] [--managed-save] [--title] { [--table] | --name | --uuid | --id } [--persistent] [--transient] [--with-managed-save] [--without-managed-save] [--autostart] [--no-autostart] [--with-snapshot] [--without-snapshot] [--with-checkpoint] [--without-checkpoint] [--state-running] [--state-paused] [--state-shutoff] [--state-other]
Prints information about existing domains.  If no options are specified it prints out information about running domains.
An example format for the list is as follows:
``virsh`` list Id    Name                           State ---------------------------------------------------- 0     Domain-0                       running 2     fedora                         paused
Name is the name of the domain.  ID the domain numeric id.  State is the run state (see below).
STATES
The State field lists what state each domain is currently in. A domain can be in one of the following possible states:
• running
The domain is currently running on a CPU
• idle
The domain is idle, and not running or runnable.  This can be caused because the domain is waiting on IO (a traditional wait state) or has gone to sleep because there was nothing else for it to do.
• paused
The domain has been paused, usually occurring through the administrator running virsh suspend.  When in a paused state the domain will still consume allocated resources like memory, but will not be eligible for scheduling by the hypervisor.
• in shutdown
The domain is in the process of shutting down, i.e. the guest operating system has been notified and should be in the process of stopping its operations gracefully.
• shut off
The domain is not running.  Usually this indicates the domain has been shut down completely, or has not been started.
• crashed
The domain has crashed, which is always a violent ending.  Usually this state can only occur if the domain has been configured not to restart on crash.
• pmsuspended
The domain has been suspended by guest power management, e.g. entered into s3 state.
Normally only active domains are listed. To list inactive domains specify --inactive or --all to list both active and inactive domains.
To further filter the list of domains you may specify one or more of filtering flags supported by the list command. These flags are grouped by function.  Specifying one or more flags from a group enables the filter group. Note that some combinations of flags may yield no results. Supported filtering flags and groups:
Persistence Flag --persistent is used to include persistent guests in the returned list. To include transient guests specify --transient.
Existence of managed save image To list domains having a managed save image specify flag --with-managed-save. For domains that don't have a managed save image specify --without-managed-save.
Domain state The following filter flags select a domain by its state: --state-running for running domains, --state-paused  for paused domains, --state-shutoff for turned off domains and --state-other for all other states as a fallback.
Autostarting domains To list autostarting domains use the flag --autostart. To list domains with this feature disabled use --no-autostart.
Snapshot existence Domains that have snapshot images can be listed using flag --with-snapshot, domains without a snapshot --without-snapshot.
Checkpoint existence Domains that have checkpoints can be listed using flag --with-checkpoint, domains without a checkpoint --without-checkpoint.
When talking to older servers, this command is forced to use a series of API calls with an inherent race, where a domain might not be listed or might appear more than once if it changed state between calls while the list was being collected.  Newer servers do not have this problem.
If --managed-save is specified, then domains that have managed save state (only possible if they are in the shut off state, so you need to specify --inactive or --all to actually list them) will instead show as saved in the listing. This flag is usable only with the default --table output. Note that this flag does not filter the list of domains.
If --name is specified, domain names are printed instead of the table formatted one per line. If --uuid is specified domain's UUID's are printed instead of names. If --id is specified then domain's ID's are printed indead of names. However, it is possible to combine --name, --uuid and --id to select only desired fields for printing. Flag --table specifies that the legacy table-formatted output should be used, but it is mutually exclusive with --name, --uuid and --id. This is the default and will be used if neither of --name, --uuid or --id is specified. If neither --name nor --uuid is specified, but --id is, then only active domains are listed, even with the --all parameter as otherwise the output would just contain bunch of lines with just -1.
If --title is specified, then the short domain description (title) is printed in an extra column. This flag is usable only with the default --table output.
$ virsh list --title Id    Name        State      Title ------------------------------------------- 0     Domain-0    running    Mailserver 1 2     fedora      paused
freecell Syntax:
freecell [{ [--cellno] cellno | --all }]
Prints the available amount of memory on the machine or within a NUMA cell.  The freecell command can provide one of three different displays of available memory on the machine depending on the options specified. With no options, it displays the total free memory on the machine.  With the --all option, it displays the free memory in each cell and the total free memory on the machine.  Finally, with a numeric argument or with --cellno plus a cell number it will display the free memory for the specified cell only.
freepages Syntax:
freepages [{ [--cellno] cellno [--pagesize] pagesize |     --all }]
Prints the available amount of pages within a NUMA cell. cellno refers to the NUMA cell you're interested in. pagesize is a scaled integer (see NOTES above).  Alternatively, if --all is used, info on each possible combination of NUMA cell and page size is printed out.
allocpages Syntax:
allocpages [--pagesize] pagesize [--pagecount] pagecount [[--cellno] cellno] [--add] [--all]
Change the size of pages pool of pagesize on the host. If --add is specified, then pagecount pages are added into the pool. However, if --add wasn't specified, then the pagecount is taken as the new absolute size of the pool (this may be used to free some pages and size the pool down). The cellno modifier can be used to narrow the modification down to a single host NUMA cell. On the other end of spectrum lies --all which executes the modification on all NUMA cells.
cpu-baseline Syntax:
cpu-baseline FILE [--features] [--migratable]
Compute baseline CPU which will be supported by all host CPUs given in <file>.  (See hypervisor-cpu-baseline command to get a CPU which can be provided by a specific hypervisor.) The list of host CPUs is built by extracting all <cpu> elements from the <file>. Thus, the <file> can contain either a set of <cpu> elements separated by new lines or even a set of complete <capabilities> elements printed by capabilities command. If --features is specified, then the resulting XML description will explicitly include all features that make up the CPU, without this option features that are part of the CPU model will not be listed in the XML description.   If --migratable is specified, features that block migration will not be included in the resulting CPU.
cpu-compare Syntax:
cpu-compare FILE [--error] [--validate]
Compare CPU definition from XML <file> with host CPU. (See hypervisor-cpu-compare command for comparing the CPU definition with the CPU which a specific hypervisor is able to provide on the host.) The XML <file> may contain either host or guest CPU definition. The host CPU definition is the <cpu> element and its contents as printed by capabilities command. The guest CPU definition is the <cpu> element and its contents from domain XML definition or the CPU definition created from the host CPU model found in domain capabilities XML (printed by domcapabilities command). In addition to the <cpu> element itself, this command accepts full domain XML, capabilities XML, or domain capabilities XML containing the CPU definition. For more information on guest CPU definition see: https://libvirt.org/formatdomain.html#elementsCPU. If --error is specified, the command will return an error when the given CPU is incompatible with host CPU and a message providing more details about the incompatibility will be printed out. If --validate is specified, validates the format of the XML document against an internal RNG schema.
cpu-models Syntax:
cpu-models arch
Print the list of CPU models known by libvirt for the specified architecture.  Whether a specific hypervisor is able to create a domain which uses any of the printed CPU models is a separate question which can be answered by looking at the domain capabilities XML returned by domcapabilities command.  Moreover, for some architectures libvirt does not know any CPU models and the usable CPU models are only limited by the hypervisor. This command will print that all CPU models are accepted for these architectures and the actual list of supported CPU models can be checked in the domain capabilities XML.
hypervisor-cpu-compare Syntax:
hypervisor-cpu-compare FILE [virttype] [emulator] [arch] [machine] [--error] [--validate]
Compare CPU definition from XML <file> with the CPU the hypervisor is able to provide on the host. (This is different from cpu-compare which compares the CPU definition with the host CPU without considering any specific hypervisor and its abilities.)
The XML FILE may contain either a host or guest CPU definition. The host CPU definition is the <cpu> element and its contents as printed by the capabilities command. The guest CPU definition is the <cpu> element and its contents from the domain XML definition or the CPU definition created from the host CPU model found in the domain capabilities XML (printed by the domcapabilities command). In addition to the <cpu> element itself, this command accepts full domain XML, capabilities XML, or domain capabilities XML containing the CPU definition. For more information on guest CPU definition see: https://libvirt.org/formatdomain.html#elementsCPU.
The virttype option specifies the virtualization type (usable in the 'type' attribute of the <domain> top level element from the domain XML). emulator specifies the path to the emulator, arch specifies the CPU architecture, and machine specifies the machine type. If --error is specified, the command will return an error when the given CPU is incompatible with the host CPU and a message providing more details about the incompatibility will be printed out.  If --validate is specified, validates the format of the XML document against an internal RNG schema.
hypervisor-cpu-baseline Syntax:
hypervisor-cpu-baseline FILE [virttype] [emulator] [arch] [machine] [--features] [--migratable]
Compute a baseline CPU which will be compatible with all CPUs defined in an XML file and with the CPU the hypervisor is able to provide on the host. (This is different from cpu-baseline which does not consider any hypervisor abilities when computing the baseline CPU.)
The XML FILE may contain either host or guest CPU definitions describing the host CPU model. The host CPU definition is the <cpu> element and its contents as printed by capabilities command. The guest CPU definition may be created from the host CPU model found in domain capabilities XML (printed by domcapabilities command). In addition to the <cpu> elements, this command accepts full capabilities XMLs, or domain capabilities XMLs containing the CPU definitions. It is recommended to use only the CPU definitions from domain capabilities, as on some architectures using the host CPU definition may either fail or provide unexpected results.
When FILE contains only a single CPU definition, the command will print the same CPU with restrictions imposed by the capabilities of the hypervisor.  Specifically, running th virsh hypervisor-cpu-baseline command with no additional options on the result of virsh domcapabilities will transform the host CPU model from domain capabilities XML to a form directly usable in domain XML.
The virttype option specifies the virtualization type (usable in the 'type' attribute of the <domain> top level element from the domain XML). emulator specifies the path to the emulator, arch specifies the CPU architecture, and machine specifies the machine type. If --features is specified, then the resulting XML description will explicitly include all features that make up the CPU, without this option features that are part of the CPU model will not be listed in the XML description. If --migratable is specified, features that block migration will not be included in the resulting CPU.
The following commands manipulate domains directly, as stated previously most commands take domain as the first parameter. The domain can be specified as a short integer, a name or a full UUID.
autostart Syntax:
autostart [--disable] domain
Configure a domain to be automatically started at boot.
The option --disable disables autostarting.
blkdeviotune Syntax:
blkdeviotune domain device [[--config] [--live] | [--current]] [[total-bytes-sec] | [read-bytes-sec] [write-bytes-sec]] [[total-iops-sec] | [read-iops-sec] [write-iops-sec]] [[total-bytes-sec-max] | [read-bytes-sec-max] [write-bytes-sec-max]] [[total-iops-sec-max] | [read-iops-sec-max] [write-iops-sec-max]] [[total-bytes-sec-max-length] | [read-bytes-sec-max-length] [write-bytes-sec-max-length]] [[total-iops-sec-max-length] | [read-iops-sec-max-length] [write-iops-sec-max-length]] [size-iops-sec] [group-name]
Set or query the block disk io parameters for a block device of domain. device specifies a unique target name (<target dev='name'/>) or source file (<source file='name'/>) for one of the disk devices attached to domain (see also domblklist for listing these names).
If no limit is specified, it will query current I/O limits setting. Otherwise, alter the limits with these flags: --total-bytes-sec specifies total throughput limit as a scaled integer, the default being bytes per second if no suffix is specified.  --read-bytes-sec specifies read throughput limit as a scaled integer, the default being bytes per second if no suffix is specified.  --write-bytes-sec specifies write throughput limit as a scaled integer, the default being bytes per second if no suffix is specified.  --total-iops-sec specifies total I/O operations limit per second.  --read-iops-sec specifies read I/O operations limit per second.  --write-iops-sec specifies write I/O operations limit per second.  --total-bytes-sec-max specifies maximum total throughput limit as a scaled integer, the default being bytes per second if no suffix is specified --read-bytes-sec-max specifies maximum read throughput limit as a scaled integer, the default being bytes per second if no suffix is specified.  --write-bytes-sec-max specifies maximum write throughput limit as a scaled integer, the default being bytes per second if no suffix is specified.  --total-iops-sec-max specifies maximum total I/O operations limit per second.  --read-iops-sec-max specifies maximum read I/O operations limit per second.  --write-iops-sec-max specifies maximum write I/O operations limit per second.  --total-bytes-sec-max-length specifies duration in seconds to allow maximum total throughput limit. --read-bytes-sec-max-length specifies duration in seconds to allow maximum read throughput limit.  --write-bytes-sec-max-length specifies duration in seconds to allow maximum write throughput limit. --total-iops-sec-max-length specifies duration in seconds to allow maximum total I/O operations limit.  --read-iops-sec-max-length specifies duration in seconds to allow maximum read I/O operations limit. --write-iops-sec-max-length specifies duration in seconds to allow maximum write I/O operations limit.  --size-iops-sec specifies size I/O operations limit per second.  --group-name specifies group name to share I/O quota between multiple drives.  For a QEMU domain, if no name is provided, then the default is to have a single group for each device.
Older versions of virsh only accepted these options with underscore instead of dash, as in --total_bytes_sec.
Bytes and iops values are independent, but setting only one value (such as --read-bytes-sec) resets the other two in that category to unlimited. An explicit 0 also clears any limit.  A non-zero value for a given total cannot be mixed with non-zero values for read or write.
It is up to the hypervisor to determine how to handle the length values. For the QEMU hypervisor, if an I/O limit value or maximum value is set, then the default value of 1 second will be displayed. Supplying a 0 will reset the value back to the default.
If --live is specified, affect a running guest.  If --config is specified, affect the next start of a persistent guest.  If --current is specified, it is equivalent to either --live or --config, depending on the current state of the guest.  When setting the disk io parameters both --live and --config flags may be given, but --current is exclusive. For querying only one of --live, --config or --current can be specified. If no flag is specified, behavior is different depending on hypervisor.
blkiotune Syntax:
blkiotune domain [--weight weight] [--device-weights device-weights] [--device-read-iops-sec device-read-iops-sec] [--device-write-iops-sec device-write-iops-sec] [--device-read-bytes-sec device-read-bytes-sec] [--device-write-bytes-sec device-write-bytes-sec] [[--config] [--live] | [--current]]
Display or set the blkio parameters. QEMU/KVM supports --weight. --weight is in range [100, 1000]. After kernel 2.6.39, the value could be in the range [10, 1000].
device-weights is a single string listing one or more device/weight pairs, in the format of /path/to/device,weight,/path/to/device,weight. Each weight is in the range [100, 1000], [10, 1000] after kernel 2.6.39, or the value 0 to remove that device from per-device listings.  Only the devices listed in the string are modified; any existing per-device weights for other devices remain unchanged.
device-read-iops-sec is a single string listing one or more device/read_iops_sec pairs, int the format of /path/to/device,read_iops_sec,/path/to/device,read_iops_sec.  Each read_iops_sec is a number which type is unsigned int, value 0 to remove that device from per-device listing.  Only the devices listed in the string are modified; any existing per-device read_iops_sec for other devices remain unchanged.
device-write-iops-sec is a single string listing one or more device/write_iops_sec pairs, int the format of /path/to/device,write_iops_sec,/path/to/device,write_iops_sec.  Each write_iops_sec is a number which type is unsigned int, value 0 to remove that device from per-device listing.  Only the devices listed in the string are modified; any existing per-device write_iops_sec for other devices remain unchanged.
device-read-bytes-sec is a single string listing one or more device/read_bytes_sec pairs, int the format of /path/to/device,read_bytes_sec,/path/to/device,read_bytes_sec.  Each read_bytes_sec is a number which type is unsigned long long, value 0 to remove that device from per-device listing.  Only the devices listed in the string are modified; any existing per-device read_bytes_sec for other devices remain unchanged.
device-write-bytes-sec is a single string listing one or more device/write_bytes_sec pairs, int the format of /path/to/device,write_bytes_sec,/path/to/device,write_bytes_sec.  Each write_bytes_sec is a number which type is unsigned long long, value 0 to remove that device from per-device listing.  Only the devices listed in the string are modified; any existing per-device write_bytes_sec for other devices remain unchanged.
If --live is specified, affect a running guest.  If --config is specified, affect the next start of a persistent guest.  If --current is specified, it is equivalent to either --live or --config, depending on the current state of the guest.  Both --live and --config flags may be given, but --current is exclusive. If no flag is specified, behavior is different depending on hypervisor.
blockcommit Syntax:
blockcommit domain path [bandwidth] [--bytes] [base] [--shallow] [top] [--delete] [--keep-relative] [--wait [--async] [--verbose]] [--timeout seconds] [--active] [{--pivot | --keep-overlay}]
Reduce the length of a backing image chain, by committing changes at the top of the chain (snapshot or delta files) into backing images.  By default, this command attempts to flatten the entire chain.  If base and/or top are specified as files within the backing chain, then the operation is constrained to committing just that portion of the chain; --shallow can be used instead of base to specify the immediate backing file of the resulting top image to be committed.  The files being committed are rendered invalid, possibly as soon as the operation starts; using the --delete flag will attempt to remove these invalidated files at the successful completion of the commit operation. When the --keep-relative flag is used, the backing file paths will be kept relative.
When top is omitted or specified as the active image, it is also possible to specify --active to trigger a two-phase active commit. In the first phase, top is copied into base and the job can only be canceled, with top still containing data not yet in base. In the second phase, top and base remain identical until a call to blockjob with the --abort flag (keeping top as the active image that tracks changes from that point in time) or the --pivot flag (making base the new active image and invalidating top).
By default, this command returns as soon as possible, and data for the entire disk is committed in the background; the progress of the operation can be checked with blockjob.  However, if --wait is specified, then this command will block until the operation completes (or for --active, enters the second phase), or until the operation is canceled because the optional timeout in seconds elapses or SIGINT is sent (usually with Ctrl-C).  Using --verbose along with --wait will produce periodic status updates.  If job cancellation is triggered, --async will return control to the user as fast as possible, otherwise the command may continue to block a little while longer until the job is done cleaning up.  Using --pivot is shorthand for combining --active --wait with an automatic blockjob --pivot; and using --keep-overlay is shorthand for combining --active --wait with an automatic blockjob --abort.
path specifies fully-qualified path of the disk; it corresponds to a unique target name (<target dev='name'/>) or source file (<source file='name'/>) for one of the disk devices attached to domain (see also domblklist for listing these names).  bandwidth specifies copying bandwidth limit in MiB/s, although for QEMU, it may be non-zero only for an online domain. For further information on the bandwidth argument see the corresponding section for the blockjob command.
blockcopy Syntax:
blockcopy domain path { dest [format] [--blockdev] | --xml file } [--shallow] [--reuse-external] [bandwidth] [--wait [--async] [--verbose]] [{--pivot | --finish}] [--timeout seconds] [granularity] [buf-size] [--bytes] [--transient-job]
Copy a disk backing image chain to a destination.  Either dest as the destination file name, or --xml with the name of an XML file containing a top-level <disk> element describing the destination, must be present. Additionally, if dest is given, format should be specified to declare the format of the destination (if format is omitted, then libvirt will reuse the format of the source, or with --reuse-external will be forced to probe the destination format, which could be a potential security hole). The command supports --raw as a boolean flag synonym for --format=raw. When using dest, the destination is treated as a regular file unless --blockdev is used to signal that it is a block device. By default, this command flattens the entire chain; but if --shallow is specified, the copy shares the backing chain.
If --reuse-external is specified, then the destination must exist and have sufficient space to hold the copy. If --shallow is used in conjunction with --reuse-external then the pre-created image must have guest visible contents identical to guest visible contents of the backing file of the original image. This may be used to modify the backing file names on the destination.
By default, the copy job runs in the background, and consists of two phases.  Initially, the job must copy all data from the source, and during this phase, the job can only be canceled to revert back to the source disk, with no guarantees about the destination.  After this phase completes, both the source and the destination remain mirrored until a call to blockjob with the --abort and --pivot flags pivots over to the copy, or a call without --pivot leaves the destination as a faithful copy of that point in time.  However, if --wait is specified, then this command will block until the mirroring phase begins, or cancel the operation if the optional timeout in seconds elapses or SIGINT is sent (usually with Ctrl-C).  Using --verbose along with --wait will produce periodic status updates.  Using --pivot (similar to blockjob --pivot) or --finish (similar to blockjob --abort) implies --wait, and will additionally end the job cleanly rather than leaving things in the mirroring phase.  If job cancellation is triggered by timeout or by --finish, --async will return control to the user as fast as possible, otherwise the command may continue to block a little while longer until the job has actually cancelled.
path specifies fully-qualified path of the disk.  bandwidth specifies copying bandwidth limit in MiB/s. Specifying a negative value is interpreted as an unsigned long long value that might be essentially unlimited, but more likely would overflow; it is safer to use 0 for that purpose. For further information on the bandwidth argument see the corresponding section for the blockjob command.  Specifying granularity allows fine-tuning of the granularity that will be copied when a dirty region is detected; larger values trigger less I/O overhead but may end up copying more data overall (the default value is usually correct); hypervisors may restrict this to be a power of two or fall within a certain range. Specifying buf-size will control how much data can be simultaneously in-flight during the copy; larger values use more memory but may allow faster completion (the default value is usually correct).
--transient-job allows specifying that the user does not require the job to be recovered if the VM crashes or is turned off before the job completes. This flag removes the restriction of copy jobs to transient domains if that restriction is applied by the hypervisor.
blockjob Syntax:
blockjob domain path { [--abort] [--async] [--pivot] | [--info] [--raw] [--bytes] | [bandwidth] }
Manage active block operations.  There are three mutually-exclusive modes: --info, bandwidth, and --abort.  --async and --pivot imply abort mode; --raw implies info mode; and if no mode was given, --info mode is assumed.
path specifies fully-qualified path of the disk; it corresponds to a unique target name (<target dev='name'/>) or source file (<source file='name'/>) for one of the disk devices attached to domain (see also domblklist for listing these names).
In --abort mode, the active job on the specified disk will be aborted. If --async is also specified, this command will return immediately, rather than waiting for the cancellation to complete.  If --pivot is specified, this requests that an active copy or active commit job be pivoted over to the new image.
In --info mode, the active job information on the specified disk will be printed.  By default, the output is a single human-readable summary line; this format may change in future versions.  Adding --raw lists each field of the struct, in a stable format.  If the --bytes flag is set, then the command errors out if the server could not supply bytes/s resolution; when omitting the flag, raw output is listed in MiB/s and human-readable output automatically selects the best resolution supported by the server.
bandwidth can be used to set bandwidth limit for the active job in MiB/s. If --bytes is specified then the bandwidth value is interpreted in bytes/s. Specifying a negative value is interpreted as an unsigned long value or essentially unlimited. The hypervisor can choose whether to reject the value or convert it to the maximum value allowed. Optionally a scaled positive number may be used as bandwidth (see NOTES above). Using --bytes with a scaled value permits a finer granularity to be selected. A scaled value used without --bytes will be rounded down to MiB/s. Note that the --bytes may be unsupported by the hypervisor.
Note that the progress reported for blockjobs corresponding to a pull-mode backup don't report progress of the backup but rather usage of temporary space required for the backup.
blockpull Syntax:
blockpull domain path [bandwidth] [--bytes] [base] [--wait [--verbose] [--timeout seconds] [--async]] [--keep-relative]
Populate a disk from its backing image chain. By default, this command flattens the entire chain; but if base is specified, containing the name of one of the backing files in the chain, then that file becomes the new backing file and only the intermediate portion of the chain is pulled. Once all requested data from the backing image chain has been pulled, the disk no longer depends on that portion of the backing chain.
By default, this command returns as soon as possible, and data for the entire disk is pulled in the background; the progress of the operation can be checked with blockjob.  However, if --wait is specified, then this command will block until the operation completes, or cancel the operation if the optional timeout in seconds elapses or SIGINT is sent (usually with Ctrl-C).  Using --verbose along with --wait will produce periodic status updates.  If job cancellation is triggered, --async will return control to the user as fast as possible, otherwise the command may continue to block a little while longer until the job is done cleaning up.
Using the --keep-relative flag will keep the backing chain names relative.
path specifies fully-qualified path of the disk; it corresponds to a unique target name (<target dev='name'/>) or source file (<source file='name'/>) for one of the disk devices attached to domain (see also domblklist for listing these names).  bandwidth specifies copying bandwidth limit in MiB/s. For further information on the bandwidth argument see the corresponding section for the blockjob command.
blockresize Syntax:
blockresize domain path size
Resize a block device of domain while the domain is running, path specifies the absolute path of the block device; it corresponds to a unique target name (<target dev='name'/>) or source file (<source file='name'/>) for one of the disk devices attached to domain (see also domblklist for listing these names).
size is a scaled integer (see NOTES above) which defaults to KiB (blocks of 1024 bytes) if there is no suffix.  You must use a suffix of "B" to get bytes (note that for historical reasons, this differs from vol-resize which defaults to bytes without a suffix).
console Syntax:
console domain [devname] [--safe] [--force]
Connect the virtual serial console for the guest. The optional devname parameter refers to the device alias of an alternate console, serial or parallel device configured for the guest.  If omitted, the primary console will be opened.
If the flag --safe is specified, the connection is only attempted if the driver supports safe console handling. This flag specifies that the server has to ensure exclusive access to console devices. Optionally the --force flag may be specified, requesting to disconnect any existing sessions, such as in a case of a broken connection.
cpu-stats Syntax:
cpu-stats domain [--total] [start] [count]
Provide cpu statistics information of a domain. The domain should be running. Default it shows stats for all CPUs, and a total. Use --total for only the total stats, start for only the per-cpu stats of the CPUs from start, count for only count CPUs' stats.
create Syntax:
create FILE [--console] [--paused] [--autodestroy] [--pass-fds N,M,...] [--validate]
Create a domain from an XML <file>. Optionally, --validate option can be passed to validate the format of the input XML file against an internal RNG schema (identical to using virt-xml-validate(1) tool). Domains created using this command are going to be either transient (temporary ones that will vanish once destroyed) or existing persistent guests that will run with one-time use configuration, leaving the persistent XML untouched (this can come handy during an automated testing of various configurations all based on the original XML).  See the example below for usage demonstration.
The domain will be paused if the --paused option is used and supported by the driver; otherwise it will be running. If --console is requested, attach to the console after creation.  If --autodestroy is requested, then the guest will be automatically destroyed when virsh closes its connection to libvirt, or otherwise exits.
If --pass-fds is specified, the argument is a comma separated list of open file descriptors which should be pass on into the guest. The file descriptors will be re-numbered in the guest, starting from 3. This is only supported with container based virtualization.
1. prepare a template from an existing domain (skip directly to 3a if writing one from scratch)
# virsh dumpxml <domain> > domain.xml
2. edit the template using an editor of your choice and:
a. DO CHANGE! <name> and <uuid> (<uuid> can also be removed), or
b. DON'T CHANGE! either <name> or <uuid>
# $EDITOR domain.xml
3. create a domain from domain.xml, depending on whether following 2a or 2b respectively:
a. the domain is going to be transient
b. an existing persistent guest will run with a modified one-time configuration
# virsh create domain.xml
define Syntax:
define FILE [--validate]
Define a domain from an XML <file>. Optionally, the format of the input XML file can be validated against an internal RNG schema with --validate (identical to using virt-xml-validate(1) tool). The domain definition is registered but not started.  If domain is already running, the changes will take effect on the next boot.
desc Syntax:
desc domain [[--live] [--config] | [--current]] [--title] [--edit] [--new-desc New description or title message]
Show or modify description and title of a domain. These values are user fields that allow storing arbitrary textual data to allow easy identification of domains. Title should be short, although it's not enforced.  (See also metadata that works with XML based domain metadata.)
Flags --live or --config select whether this command works on live or persistent definitions of the domain. If both --live and --config are specified, the --config option takes precedence on getting the current description and both live configuration and config are updated while setting the description. --current is exclusive and implied if none of these was specified.
Flag --edit specifies that an editor with the contents of current description or title should be opened and the contents saved back afterwards.
Flag --title selects operation on the title field instead of description.
If neither of --edit and --new-desc are specified the note or description is displayed instead of being modified.
destroy Syntax:
destroy domain [--graceful]
Immediately terminate the domain domain.  This doesn't give the domain OS any chance to react, and it's the equivalent of ripping the power cord out on a physical machine.  In most cases you will want to use the shutdown command instead.  However, this does not delete any storage volumes used by the guest, and if the domain is persistent, it can be restarted later.
If domain is transient, then the metadata of any snapshots will be lost once the guest stops running, but the snapshot contents still exist, and a new domain with the same name and UUID can restore the snapshot metadata with snapshot-create.  Similarly, the metadata of any checkpoints will be lost, but can be restored with checkpoint-create.
If --graceful is specified, don't resort to extreme measures (e.g. SIGKILL) when the guest doesn't stop after a reasonable timeout; return an error instead.
domblkerror Syntax:
domblkerror domain
Show errors on block devices.  This command usually comes handy when domstate command says that a domain was paused due to I/O error.  The domblkerror command lists all block devices in error state and the error seen on each of them.
domblkinfo Syntax:
domblkinfo domain [block-device --all] [--human]
Get block device size info for a domain.  A block-device corresponds to a unique target name (<target dev='name'/>) or source file (<source file='name'/>) for one of the disk devices attached to domain (see also domblklist for listing these names). If --human is set, the output will have a human readable output.  If --all is set, the output will be a table showing all block devices size info associated with domain.  The --all option takes precedence of the others.
domblklist Syntax:
domblklist domain [--inactive] [--details]
Print a table showing the brief information of all block devices associated with domain. If --inactive is specified, query the block devices that will be used on the next boot, rather than those currently in use by a running domain. If --details is specified, disk type and device value will also be printed. Other contexts that require a block device name (such as domblkinfo or snapshot-create for disk snapshots) will accept either target or unique source names printed by this command.
domblkstat Syntax:
domblkstat domain [block-device] [--human]
Get device block stats for a running domain.  A block-device corresponds to a unique target name (<target dev='name'/>) or source file (<source file='name'/>) for one of the disk devices attached to domain (see also domblklist for listing these names). On a LXC or QEMU domain, omitting the block-device yields device block stats summarily for the entire domain.
Use --human for a more human readable output.
Availability of these fields depends on hypervisor. Unsupported fields are missing from the output. Other fields may appear if communicating with a newer version of libvirtd.
Explanation of fields (fields appear in the following order):
• rd_req            - count of read operations
• rd_bytes          - count of read bytes
• wr_req            - count of write operations
• wr_bytes          - count of written bytes
• errs              - error count
• flush_operations  - count of flush operations
• rd_total_times    - total time read operations took (ns)
• wr_total_times    - total time write operations took (ns)
• flush_total_times - total time flush operations took (ns)
• <-- other fields provided by hypervisor -->
domblkthreshold Syntax:
domblkthreshold domain dev threshold
Set the threshold value for delivering the block-threshold event. dev specifies the disk device target or backing chain element of given device using the 'target[1]' syntax. threshold is a scaled value of the offset. If the block device should write beyond that offset the event will be delivered.
domcontrol Syntax:
domcontrol domain
Returns state of an interface to VMM used to control a domain.  For states other than "ok" or "error" the command also prints number of seconds elapsed since the control interface entered its current state.
domdirtyrate-calc Syntax:
domdirtyrate-calc <domain> [--seconds <sec>]
Calculate an active domain's memory dirty rate which may be expected by user in order to decide whether it's proper to be migrated out or not. The seconds parameter can be used to calculate dirty rate in a specific time which allows 60s at most now and would be default to 1s if missing. The calculated dirty rate information is available by calling 'domstats --dirtyrate'.
domdisplay Syntax:
domdisplay domain [--include-password] [[--type] type] [--all]
Output a URI which can be used to connect to the graphical display of the domain via VNC, SPICE or RDP.  The particular graphical display type can be selected using the type parameter (e.g. "vnc", "spice", "rdp").  If --include-password is specified, the SPICE channel password will be included in the URI. If --all is specified, then all show all possible graphical displays, for a VM could have more than one graphical displays.
domfsfreeze Syntax:
domfsfreeze domain [[--mountpoint] mountpoint...]
Freeze mounted filesystems within a running domain to prepare for consistent snapshots.
The --mountpoint option takes a parameter mountpoint, which is a mount point path of the filesystem to be frozen. This option can occur multiple times. If this is not specified, every mounted filesystem is frozen.
Note: snapshot-create command has a --quiesce option to freeze and thaw the filesystems automatically to keep snapshots consistent.  domfsfreeze command is only needed when a user wants to utilize the native snapshot features of storage devices not supported by libvirt.
domfsinfo Syntax:
domfsinfo domain
Show a list of mounted filesystems within the running domain. The list contains mountpoints, names of a mounted device in the guest, filesystem types, and unique target names used in the domain XML (<target dev='name'/>).
Note that this command requires a guest agent configured and running in the domain's guest OS.
domfsthaw Syntax:
domfsthaw domain [[--mountpoint] mountpoint...]
Thaw mounted filesystems within a running domain, which have been frozen by domfsfreeze command.
The --mountpoint option takes a parameter mountpoint, which is a mount point path of the filesystem to be thawed. This option can occur multiple times. If this is not specified, every mounted filesystem is thawed.
domfstrim Syntax:
domfstrim domain [--minimum bytes] [--mountpoint mountPoint]
Issue a fstrim command on all mounted filesystems within a running domain. It discards blocks which are not in use by the filesystem.  If --minimum bytes is specified, it tells guest kernel length of contiguous free range. Smaller than this may be ignored (this is a hint and the guest may not respect it). By increasing this value, the fstrim operation will complete more quickly for filesystems with badly fragmented free space, although not all blocks will be discarded.  The default value is zero, meaning "discard every free block". Moreover, if a user wants to trim only one mount point, it can be specified via optional --mountpoint parameter.
domhostname Syntax:
domhostname domain [--source lease|agent]
Returns the hostname of a domain, if the hypervisor makes it available.
The --source argument specifies what data source to use for the hostnames, currently 'lease' to read DHCP leases or 'agent' to query the guest OS via an agent. If unspecified, driver returns the default method available (some drivers support only one type of source).
domid Syntax:
domid domain-name-or-uuid
Convert a domain name (or UUID) to a domain id
domif-getlink Syntax:
domif-getlink domain interface-device [--config]
Query link state of the domain's virtual interface. If --config is specified, query the persistent configuration, for compatibility purposes, --persistent is alias of --config.
interface-device can be the interface's target name or the MAC address.
domif-setlink Syntax:
domif-setlink domain interface-device state [--config]
Modify link state of the domain's virtual interface. Possible values for state are "up" and "down". If --config is specified, only the persistent configuration of the domain is modified, for compatibility purposes, --persistent is alias of --config.  interface-device can be the interface's target name or the MAC address.
domifaddr Syntax:
domifaddr domain [interface] [--full] [--source lease|agent|arp]
Get a list of interfaces of a running domain along with their IP and MAC addresses, or limited output just for one interface if interface is specified. Note that interface can be driver dependent, it can be the name within guest OS or the name you would see in domain XML. Moreover, the whole command may require a guest agent to be configured for the queried domain under some hypervisors, notably QEMU.
If --full is specified, the interface name and MAC address is always displayed when the interface has multiple IP addresses or aliases; otherwise, only the interface name and MAC address is displayed for the first name and MAC address with "-" for the others using the same name and MAC address.
The --source argument specifies what data source to use for the addresses, currently 'lease' to read DHCP leases, 'agent' to query the guest OS via an agent, or 'arp' to get IP from host's arp tables.  If unspecified, 'lease' is the default.
backup-begin Syntax:
backup-begin domain [backupxml] [checkpointxml] [--reuse-external]
Begin a new backup job. If backupxml is omitted, this defaults to a full backup using a push model to filenames generated by libvirt; supplying XML allows fine-tuning such as requesting an incremental backup relative to an earlier checkpoint, controlling which disks participate or which filenames are involved, or requesting the use of a pull model backup. The backup-dumpxml command shows any resulting values assigned by libvirt. For more information on backup XML, see: https://libvirt.org/formatbackup.html
If --reuse-external is used it instructs libvirt to reuse temporary and output files provided by the user in backupxml.
If checkpointxml is specified, a second file with a top-level element of domaincheckpoint is used to create a simultaneous checkpoint, for doing a later incremental backup relative to the time the backup was created. See checkpoint-create for more details on checkpoints.
This command returns as soon as possible, and the backup job runs in the background; the progress of a push model backup can be checked with domjobinfo or by waiting for an event with event (the progress of a pull model backup is under the control of whatever third party connects to the NBD export). The job is ended with domjobabort.
backup-dumpxml Syntax:
backup-dumpxml domain
Output XML describing the current backup job.
domiflist Syntax:
domiflist domain [--inactive]
Print a table showing the brief information of all virtual interfaces associated with domain. If --inactive is specified, query the virtual interfaces that will be used on the next boot, rather than those currently in use by a running domain. Other contexts that require a MAC address of virtual interface (such as detach-interface or domif-setlink) will accept the MAC address printed by this command.
domifstat Syntax:
domifstat domain interface-device
Get network interface stats for a running domain. The network interface stats are only available for interfaces that have a physical source interface. This does not include, for example, a 'user' interface type since it is a virtual LAN with NAT to the outside world. interface-device can be the interface target by name or MAC address.
domiftune Syntax:
domiftune domain interface-device [[--config] [--live] | [--current]] [*--inbound average,peak,burst,floor*] [*--outbound average,peak,burst*]
Set or query the domain's network interface's bandwidth parameters. interface-device can be the interface's target name (<target dev='name'/>), or the MAC address.
If no --inbound or --outbound is specified, this command will query and show the bandwidth settings. Otherwise, it will set the inbound or outbound bandwidth. average,peak,burst,floor is the same as in command attach-interface.  Values for average, peak and floor are expressed in kilobytes per second, while burst is expressed in kilobytes in a single burst at peak speed as described in the Network XML documentation at https://libvirt.org/formatnetwork.html#elementQoS.
To clear inbound or outbound settings, use --inbound or --outbound respectfully with average value of zero.
dominfo Syntax:
dominfo domain
Returns basic information about the domain.
domjobabort Syntax:
domjobabort domain
Abort the currently running domain job.
domjobinfo Syntax:
domjobinfo domain [--completed [--keep-completed]] [--anystats] [--rawstats]
Returns information about jobs running on a domain. --completed tells virsh to return information about a recently finished job. Statistics of a completed job are automatically destroyed once read (unless --keep-completed is used) or when libvirtd is restarted.