neulab/tldr huggingface dataset:
Switch the current migration from pre-copy to post-copy. This is only supported for a migration started with --postcopy option.
migrate-setmaxdowntime Syntax:
migrate-setmaxdowntime domain downtime
Set maximum tolerable downtime for a domain which is being live-migrated to another host.  The downtime is a number of milliseconds the guest is allowed to be down at the end of live migration.
migrate-setspeed Syntax:
migrate-setspeed domain bandwidth [--postcopy]
Set the maximum migration bandwidth (in MiB/s) for a domain which is being migrated to another host. bandwidth is interpreted as an unsigned long long value. Specifying a negative value results in an essentially unlimited value being provided to the hypervisor. The hypervisor can choose whether to reject the value or convert it to the maximum value allowed. If the --postcopy option is specified, the command will set the maximum bandwidth allowed during a post-copy migration phase.
numatune Syntax:
numatune domain [--mode mode] [--nodeset nodeset] [[--config] [--live] | [--current]]
Set or get a domain's numa parameters, corresponding to the <numatune> element of domain XML.  Without flags, the current settings are displayed.
mode can be one of `strict', `interleave' and `preferred' or any valid number from the virDomainNumatuneMemMode enum in case the daemon supports it.  For a running domain, the mode can't be changed, and the nodeset can be changed only if the domain was started with a mode of `strict'.
nodeset is a list of numa nodes used by the host for running the domain. Its syntax is a comma separated list, with '-' for ranges and '^' for excluding a node.
If --live is specified, set scheduler information of 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.
For running guests in Linux hosts, the changes made in the domain's numa parameters does not imply that the guest memory will be moved to a different nodeset immediately. The memory migration depends on the guest activity, and the memory of an idle guest will remain in its previous nodeset for longer. The presence of VFIO devices will also lock parts of the guest memory in the same nodeset used to start the guest, regardless of nodeset changes.
perf Syntax:
perf domain [--enable eventSpec] [--disable eventSpec] [[--config] [--live] | [--current]]
Get the current perf events setting or enable/disable specific perf events for a guest domain.
Perf is a performance analyzing tool in Linux, and it can instrument CPU performance counters, tracepoints, kprobes, and uprobes (dynamic tracing). Perf supports a list of measurable events, and can measure events coming from different sources. For instance, some event are pure kernel counters, in this case they are called software events, including context-switches, minor-faults, etc.. Now dozens of events from different sources can be supported by perf.
Currently only QEMU/KVM supports this command. The --enable and --disable option combined with eventSpec can be used to enable or disable specific performance event. eventSpec is a string list of one or more events separated by commas. Valid event names are as follows:
Valid perf event names
• cmt - A PQos (Platform Qos) feature to monitor the usage of cache by applications running on the platform.
• mbmt - Provides a way to monitor the total system memory bandwidth between one level of cache and another.
• mbml - Provides a way to limit the amount of data (bytes/s) send through the memory controller on the socket.
• cache_misses - Provides the count of cache misses by applications running on the platform.
• cache_references - Provides the count of cache hits by applications running on th e platform.
• instructions - Provides the count of instructions executed by applications running on the platform.
• cpu_cycles - Provides the count of cpu cycles (total/elapsed). May be used with instructions in order to get a cycles per instruction.
• branch_instructions - Provides the count of branch instructions executed by applications running on the platform.
• branch_misses - Provides the count of branch misses executed by applications running on the platform.
• bus_cycles - Provides the count of bus cycles executed by applications running on the platform.
• stalled_cycles_frontend - Provides the count of stalled cpu cycles in the frontend of the instruction processor pipeline by applications running on the platform.
• stalled_cycles_backend - Provides the count of stalled cpu cycles in the backend of the instruction processor pipeline by applications running on the platform.
• ref_cpu_cycles -  Provides the count of total cpu cycles not affected by CPU frequency scaling by applications running on the platform.
• cpu_clock - Provides the cpu clock time consumed by applications running on the platform.
• task_clock - Provides the task clock time consumed by applications running on the platform.
• page_faults - Provides the count of page faults by applications running on the platform.
• context_switches - Provides the count of context switches by applications running on the platform.
• cpu_migrations - Provides the count cpu migrations by applications running on the platform.
• page_faults_min - Provides the count minor page faults by applications running on the platform.
• page_faults_maj - Provides the count major page faults by applications running on the platform.
• alignment_faults - Provides the count alignment faults by applications running on the platform.
• emulation_faults - Provides the count emulation faults by applications running on the platform.
Note: The statistics can be retrieved using the domstats command using the --perf flag.
reboot Syntax:
reboot domain [--mode MODE-LIST]
Reboot a domain.  This acts just as if the domain had the reboot command run from the console.  The command returns as soon as it has executed the reboot action, which may be significantly before the domain actually reboots.
The exact behavior of a domain when it reboots is set by the on_reboot parameter in the domain's XML definition.
By default the hypervisor will try to pick a suitable shutdown method. To specify an alternative method, the --mode parameter can specify a comma separated list which includes acpi, agent, initctl, signal and paravirt. The order in which drivers will try each mode is undefined, and not related to the order specified to virsh.  For strict control over ordering, use a single mode at a time and repeat the command.
reset Syntax:
Reset a domain immediately without any guest shutdown. reset emulates the power reset button on a machine, where all guest hardware sees the RST line set and reinitializes internal state.
Note: Reset without any guest OS shutdown risks data loss.
restore Syntax:
restore state-file [--bypass-cache] [--xml file] [{--running | --paused}]
Restores a domain from a virsh save state file. See save for more info.
If --bypass-cache is specified, the restore will avoid the file system cache, although this may slow down the operation.
--xml file is usually omitted, but can be used to supply an alternative XML file for use on the restored guest with changes only in the host-specific portions of the domain XML.  For example, it can be used to account for file naming differences in underlying storage due to disk snapshots taken after the guest was saved.
Normally, restoring a saved image will use the state recorded in the save image to decide between running or paused; passing either the --running or --paused flag will allow overriding which state the domain should be started in.
Note: To avoid corrupting file system contents within the domain, you should not reuse the saved state file for a second restore unless you have also reverted all storage volumes back to the same contents as when the state file was created.
resume Syntax:
resume domain
Moves a domain out of the suspended state.  This will allow a previously suspended domain to now be eligible for scheduling by the underlying hypervisor.
save Syntax:
save domain state-file [--bypass-cache] [--xml file] [{--running | --paused}] [--verbose]
Saves a running domain (RAM, but not disk state) to a state file so that it can be restored later.  Once saved, the domain will no longer be running on the system, thus the memory allocated for the domain will be free for other domains to use.  virsh restore restores from this state file.  If --bypass-cache is specified, the save will avoid the file system cache, although this may slow down the operation.
The progress may be monitored using domjobinfo virsh command and canceled with domjobabort command (sent by another virsh instance). Another option is to send SIGINT (usually with Ctrl-C) to the virsh process running save command. --verbose displays the progress of save.
This is roughly equivalent to doing a hibernate on a running computer, with all the same limitations.  Open network connections may be severed upon restore, as TCP timeouts may have expired.
--xml file is usually omitted, but can be used to supply an alternative XML file for use on the restored guest with changes only in the host-specific portions of the domain XML.  For example, it can be used to account for file naming differences that are planned to be made via disk snapshots of underlying storage after the guest is saved.
Normally, restoring a saved image will decide between running or paused based on the state the domain was in when the save was done; passing either the --running or --paused flag will allow overriding which state the restore should use.
Domain saved state files assume that disk images will be unchanged between the creation and restore point.  For a more complete system restore point, where the disk state is saved alongside the memory state, see the snapshot family of commands.
save-image-define Syntax:
save-image-define file xml [{--running | --paused}]
Update the domain XML that will be used when file is later used in the restore command.  The xml argument must be a file name containing the alternative XML, with changes only in the host-specific portions of the domain XML.  For example, it can be used to account for file naming differences resulting from creating disk snapshots of underlying storage after the guest was saved.
The save image records whether the domain should be restored to a running or paused state.  Normally, this command does not alter the recorded state; passing either the --running or --paused flag will allow overriding which state the restore should use.
save-image-dumpxml Syntax:
save-image-dumpxml file [--security-info]
Extract the domain XML that was in effect at the time the saved state file file was created with the save command.  Using --security-info will also include security sensitive information.
save-image-edit Syntax:
save-image-edit file [{--running | --paused}]
Edit the XML configuration associated with a saved state file file created by the save command.
virsh save-image-dumpxml state-file > state-file.xml vi state-file.xml (or make changes with your other text editor) virsh save-image-define state-file state-file-xml
schedinfo Syntax:
schedinfo domain [[--config] [--live] | [--current]] [[--set] parameter=value]... schedinfo [--weight number] [--cap number] domain
Allows you to show (and set) the domain scheduler parameters. The parameters available for each hypervisor are:
LXC (posix scheduler) : cpu_shares, vcpu_period, vcpu_quota
QEMU/KVM (posix scheduler): cpu_shares, vcpu_period, vcpu_quota, emulator_period, emulator_quota, global_period, global_quota, iothread_period, iothread_quota
Xen (credit scheduler): weight, cap
ESX (allocation scheduler): reservation, limit, shares
Note: The cpu_shares parameter has a valid value range of 2-262144.
Note: The weight and cap parameters are defined only for the XEN_CREDIT scheduler.
Note: The vcpu_period, emulator_period, and iothread_period parameters have a valid value range of 1000-1000000 or 0, and the vcpu_quota, emulator_quota, and iothread_quota parameters have a valid value range of 1000-17592186044415 or less than 0. The value 0 for either parameter is the same as not specifying that parameter.
screenshot Syntax:
screenshot domain [imagefilepath] [--screen screenID]
Takes a screenshot of a current domain console and stores it into a file. Optionally, if the hypervisor supports more displays for a domain, screenID allows specifying which screen will be captured. It is the sequential number of screen. In case of multiple graphics cards, heads are enumerated before devices, e.g. having two graphics cards, both with four heads, screen ID 5 addresses the second head on the second card.
send-key Syntax:
send-key domain [--codeset codeset] [--holdtime holdtime] keycode...
Parse the keycode sequence as keystrokes to send to domain.  Each keycode can either be a numeric value or a symbolic name from the corresponding codeset.  If --holdtime is given, each keystroke will be held for that many milliseconds.  The default codeset is linux, but use of the --codeset option allows other codesets to be chosen.
If multiple keycodes are specified, they are all sent simultaneously to the guest, and they may be received in random order. If you need distinct keypresses, you must use multiple send-key invocations.
• linux
The numeric values are those defined by the Linux generic input event subsystem. The symbolic names match the corresponding Linux key constant macro names.
See virkeycode-linux(7) and virkeyname-linux(7)
• xt
The numeric values are those defined by the original XT keyboard controller. No symbolic names are provided
See virkeycode-xt(7)
• atset1
The numeric values are those defined by the AT keyboard controller, set 1 (aka XT compatible set). Extended keycoes from atset1 may differ from extended keycodes in the xt codeset. No symbolic names are provided
See virkeycode-atset1(7)
• atset2
The numeric values are those defined by the AT keyboard controller, set 2. No symbolic names are provided
See virkeycode-atset2(7)
• atset3
The numeric values are those defined by the AT keyboard controller, set 3 (aka PS/2 compatible set). No symbolic names are provided
See virkeycode-atset3(7)
• os_x
The numeric values are those defined by the macOS keyboard input subsystem. The symbolic names match the corresponding macOS key constant macro names
See virkeycode-osx(7) and virkeyname-osx(7)
• xt_kbd
The numeric values are those defined by the Linux KBD device.  These are a variant on the original XT codeset, but often with different encoding for extended keycodes. No symbolic names are provided.
See virkeycode-xtkbd(7)
• win32
The numeric values are those defined by the Win32 keyboard input subsystem. The symbolic names match the corresponding Win32 key constant macro names
See virkeycode-win32(7) and virkeyname-win32(7)
• usb
The numeric values are those defined by the USB HID specification for keyboard input. No symbolic names are provided
See virkeycode-usb(7)
• qnum
The numeric values are those defined by the QNUM extension for sending raw keycodes. These are a variant on the XT codeset, but extended keycodes have the low bit of the second byte set, instead of the high bit of the first byte. No symbolic names are provided.
See virkeycode-qnum(7)
# send three strokes 'k', 'e', 'y', using xt codeset. these # are all pressed simultaneously and may be received by the guest # in random order virsh send-key dom --codeset xt 37 18 21
# send one stroke 'right-ctrl+C' virsh send-key dom KEY_RIGHTCTRL KEY_C
# send a tab, held for 1 second virsh send-key --holdtime 1000 0xf
send-process-signal Syntax:
send-process-signal domain-id pid signame
Send a signal signame to the process identified by pid running in the virtual domain domain-id. The pid is a process ID in the virtual domain namespace.
The signame argument may be either an integer signal constant number, or one of the symbolic names:
"nop", "hup", "int", "quit", "ill", "trap", "abrt", "bus", "fpe", "kill", "usr1", "segv", "usr2", "pipe", "alrm", "term", "stkflt", "chld", "cont", "stop", "tstp", "ttin", "ttou", "urg", "xcpu", "xfsz", "vtalrm", "prof", "winch", "poll", "pwr", "sys", "rt0", "rt1", "rt2", "rt3", "rt4", "rt5", "rt6", "rt7", "rt8", "rt9", "rt10", "rt11", "rt12", "rt13", "rt14", "rt15", "rt16", "rt17", "rt18", "rt19", "rt20", "rt21", "rt22", "rt23", "rt24", "rt25", "rt26", "rt27", "rt28", "rt29", "rt30", "rt31", "rt32"
The symbol name may optionally be prefixed with sig or sig_ and may be in uppercase or lowercase.
virsh send-process-signal myguest 1 15 virsh send-process-signal myguest 1 term virsh send-process-signal myguest 1 sigterm virsh send-process-signal myguest 1 SIG_HUP
set-lifecycle-action Syntax:
set-lifecycle-action domain type action [[--config] [--live] | [--current]]
Set the lifecycle action for specified lifecycle type.  The valid types are "poweroff", "reboot" and "crash", and for each of them valid action is one of "destroy", "restart", "rename-restart", "preserve".  For type "crash", additional actions "coredump-destroy" and "coredump-restart" are supported.
set-user-password Syntax:
set-user-password domain user password [--encrypted]
Set the password for the user account in the guest domain.
If --encrypted is specified, the password is assumed to be already encrypted by the method required by the guest OS.
For QEMU/KVM, this requires the guest agent to be configured and running.
set-user-sshkeys Syntax:
set-user-sshkeys domain user [--file FILE] [{--reset | --remove}]
Append keys read from FILE into user's SSH authorized keys file in the guest domain.  In the FILE keys must be on separate lines and each line must follow authorized keys format as defined by sshd(8).
If --reset is specified, then the guest authorized keys file content is removed before appending new keys. As a special case, if --reset is provided and no FILE was provided then no new keys are added and the authorized keys file is cleared out.
If --remove is specified, then instead of adding any new keys then keys read from FILE are removed from the authorized keys file. It is not considered an error if the key does not exist in the file.
setmaxmem Syntax:
setmaxmem domain size [[--config] [--live] | [--current]]
Change the maximum memory allocation limit for a guest domain.  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.
Some hypervisors such as QEMU/KVM don't support live changes (especially increasing) of the maximum memory limit.  Even persistent configuration changes might not be performed with some hypervisors/configuration (e.g. on NUMA enabled domains on QEMU).  For complex configuration changes use command edit instead).
size is a scaled integer (see NOTES above); it defaults to kibibytes (blocks of 1024 bytes) unless you provide a suffix (and the older option name --kilobytes is available as a deprecated synonym) .  Libvirt rounds up to the nearest kibibyte.  Some hypervisors require a larger granularity than KiB, and requests that are not an even multiple will be rounded up.  For example, vSphere/ESX rounds the parameter up to mebibytes (1024 kibibytes).
setmem Syntax:
setmem domain size [[--config] [--live] | [--current]]
Change the memory allocation for a guest domain.  If --live is specified, perform a memory balloon of 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.
For Xen, you can only adjust the memory of a running domain if the domain is paravirtualized or running the PV balloon driver.
For LXC, the value being set is the cgroups value for limit_in_bytes or the maximum amount of user memory (including file cache). When viewing memory inside the container, this is the /proc/meminfo "MemTotal" value. When viewing the value from the host, use the virsh memtune command. In order to view the current memory in use and the maximum value allowed to set memory, use the virsh dominfo command.
setvcpus Syntax:
setvcpus domain count [--maximum] [[--config] [--live] | [--current]] [--guest] [--hotpluggable]
Change the number of virtual CPUs active in a guest domain.  By default, this command works on active guest domains.  To change the settings for an inactive guest domain, use the --config flag.
The count value may be limited by host, hypervisor, or a limit coming from the original description of the guest domain. For Xen, you can only adjust the virtual CPUs of a running domain if the domain is paravirtualized.
If the --config flag is specified, the change is made to the stored XML configuration for the guest domain, and will only take effect when the guest domain is next started.
If --live is specified, the guest domain must be active, and the change takes place immediately.  Both the --config and --live flags may be specified together if supported by the hypervisor.  If this command is run before the guest has finished booting, the guest may fail to process the change.
If --current is specified, it is equivalent to either --live or --config, depending on the current state of the guest.
When no flags are given, the --live flag is assumed and the guest domain must be active.  In this situation it is up to the hypervisor whether the --config flag is also assumed, and therefore whether the XML configuration is adjusted to make the change persistent.
If --guest is specified, then the count of cpus is modified in the guest instead of the hypervisor. This flag is usable only for live domains and may require guest agent to be configured in the guest.
To allow adding vcpus to persistent definitions that can be later hotunplugged after the domain is booted it is necessary to specify the --hotpluggable flag. Vcpus added to live domains supporting vcpu unplug are automatically marked as hotpluggable.
The --maximum flag controls the maximum number of virtual cpus that can be hot-plugged the next time the domain is booted.  As such, it must only be used with the --config flag, and not with the --live or the --current flag. Note that it may not be possible to change the maximum vcpu count if the processor topology is specified for the guest.
setvcpu Syntax:
setvcpu domain vcpulist [--enable] | [--disable] [[--live] [--config] | [--current]]
Change state of individual vCPUs using hot(un)plug mechanism.
See vcpupin for information on format of vcpulist. Hypervisor drivers may require that vcpulist contains exactly vCPUs belonging to one hotpluggable entity. This is usually just a single vCPU but certain architectures such as ppc64 require a full core to be specified at once.
Note that hypervisors may refuse to disable certain vcpus such as vcpu 0 or others.
If --live is specified, affect a running domain.  If --config is specified, affect the next startup of a persistent guest.  If --current is specified, it is equivalent to either --live or --config, depending on the current state of the guest.  This is the default. Both --live and --config flags may be given, but --current is exclusive.
shutdown Syntax:
shutdown domain [--mode MODE-LIST]
Gracefully shuts down a domain.  This coordinates with the domain OS to perform graceful shutdown, so there is no guarantee that it will succeed, and may take a variable length of time depending on what services must be shutdown in the domain.
The exact behavior of a domain when it shuts down is set by the on_poweroff parameter in the domain's XML definition.
If domain is transient, then the metadata of any snapshots and checkpoints will be lost once the guest stops running, but the underlying contents still exist, and a new domain with the same name and UUID can restore the snapshot metadata with snapshot-create, and the checkpoint metadata with checkpoint-create.
start Syntax:
start domain-name-or-uuid [--console] [--paused] [--autodestroy] [--bypass-cache] [--force-boot] [--pass-fds N,M,...]
Start a (previously defined) inactive domain, either from the last managedsave state, or via a fresh boot if no managedsave state is present.  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 --bypass-cache is specified, and managedsave state exists, the restore will avoid the file system cache, although this may slow down the operation.  If --force-boot is specified, then any managedsave state is discarded and a fresh boot occurs.
suspend Syntax:
suspend domain
Suspend a running domain. It is kept in memory but won't be scheduled anymore.
ttyconsole Syntax:
ttyconsole domain
Output the device used for the TTY console of the domain. If the information is not available the processes will provide an exit code of 1.
undefine Syntax:
undefine domain [--managed-save] [--snapshots-metadata] [--checkpoints-metadata] [--nvram] [--keep-nvram] [ {--storage volumes | --remove-all-storage [--delete-storage-volume-snapshots]} --wipe-storage]
Undefine a domain. If the domain is running, this converts it to a transient domain, without stopping it. If the domain is inactive, the domain configuration is removed.
The --managed-save flag guarantees that any managed save image (see the managedsave command) is also cleaned up.  Without the flag, attempts to undefine a domain with a managed save image will fail.
The --snapshots-metadata flag guarantees that any snapshots (see the snapshot-list command) are also cleaned up when undefining an inactive domain.  Without the flag, attempts to undefine an inactive domain with snapshot metadata will fail.  If the domain is active, this flag is ignored.
The --checkpoints-metadata flag guarantees that any checkpoints (see the checkpoint-list command) are also cleaned up when undefining an inactive domain.  Without the flag, attempts to undefine an inactive domain with checkpoint metadata will fail.  If the domain is active, this flag is ignored.
--nvram and --keep-nvram specify accordingly to delete or keep nvram (/domain/os/nvram/) file. If the domain has an nvram file and the flags are omitted, the undefine will fail.
The --storage flag takes a parameter volumes, which is a comma separated list of volume target names or source paths of storage volumes to be removed along with the undefined domain. Volumes can be undefined and thus removed only on inactive domains. Volume deletion is only attempted after the domain is undefined; if not all of the requested volumes could be deleted, the error message indicates what still remains behind. If a volume path is not found in the domain definition, it's treated as if the volume was successfully deleted. Only volumes managed by libvirt in storage pools can be removed this way.  (See domblklist for list of target names associated to a domain).  Example: --storage vda,/path/to/storage.img
The --remove-all-storage flag specifies that all of the domain's storage volumes should be deleted.
The --delete-storage-volume-snapshots (previously --delete-snapshots) flag specifies that any snapshots associated with the storage volume should be deleted as well. Requires the --remove-all-storage flag to be provided. Not all storage drivers support this option, presently only rbd. Using this when also removing volumes handled by a storage driver which does not support the flag will result in failure.
The flag --wipe-storage specifies that the storage volumes should be wiped before removal.
NOTE: For an inactive domain, the domain name or UUID must be used as the domain.
vcpucount Syntax:
vcpucount domain  [{--maximum | --active} {--config | --live | --current}] [--guest]
Print information about the virtual cpu counts of the given domain.  If no flags are specified, all possible counts are listed in a table; otherwise, the output is limited to just the numeric value requested. For historical reasons, the table lists the label "current" on the rows that can be queried in isolation via the --active flag, rather than relating to the --current flag.
--maximum requests information on the maximum cap of vcpus that a domain can add via setvcpus, while --active shows the current usage; these two flags cannot both be specified.  --config requires a persistent guest and requests information regarding the next time the domain will be booted, --live requires a running domain and lists current values, and --current queries according to the current state of the domain (corresponding to --live if running, or --config if inactive); these three flags are mutually exclusive.
If --guest is specified, then the count of cpus is reported from the perspective of the guest. This flag is usable only for live domains and may require guest agent to be configured in the guest.
vcpuinfo Syntax:
vcpuinfo domain [--pretty]
Returns basic information about the domain virtual CPUs, like the number of vCPUs, the running time, the affinity to physical processors.
With --pretty, cpu affinities are shown as ranges.
$ virsh vcpuinfo fedora VCPU:           0 CPU:            0 State:          running CPU time:       7,0s CPU Affinity:   yyyy
VCPU:           1 CPU:            1 State:          running CPU time:       0,7s CPU Affinity:   yyyy
The State field displays the current operating state of a virtual CPU
• offline
The virtual CPU is offline and not usable by the domain.  This state is not supported by all hypervisors.
The virtual CPU is available to the domain and is operating.
• blocked
The virtual CPU is available to the domain but is waiting for a resource.  This state is not supported by all hypervisors, in which case running may be reported instead.
• no state
The virtual CPU state could not be determined. This could happen if the hypervisor is newer than virsh.
• N/A
There's no information about the virtual CPU state available. This can be the case if the domain is not running or the hypervisor does not report the virtual CPU state.
vcpupin Syntax:
vcpupin domain [vcpu] [cpulist] [[--live] [--config] | [--current]]
Query or change the pinning of domain VCPUs to host physical CPUs.  To pin a single vcpu, specify cpulist; otherwise, you can query one vcpu or omit vcpu to list all at once.
cpulist is a list of physical CPU numbers. Its syntax is a comma separated list and a special markup using '-' and '^' (ex. '0-4', '0-3,^2') can also be allowed. The '-' denotes the range and the '^' denotes exclusive.  For pinning the vcpu to all physical cpus specify 'r' as a cpulist.  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 if cpulist is present, but --current is exclusive.  If no flag is specified, behavior is different depending on hypervisor.
vncdisplay Syntax:
vncdisplay domain
Output the IP address and port number for the VNC display. If the information is not available the processes will provide an exit code of 1.
The following commands manipulate devices associated to domains.  The domain can be specified as a short integer, a name or a full UUID.  To better understand the values allowed as options for the command reading the documentation at https://libvirt.org/formatdomain.html on the format of the device sections to get the most accurate set of accepted values.
attach-device Syntax:
attach-device domain FILE [[[--live] [--config] | [--current]] | [--persistent]]
Attach a device to the domain, using a device definition in an XML file using a device definition element such as <disk> or <interface> as the top-level element.  See the documentation at https://libvirt.org/formatdomain.html#elementsDevices to learn about libvirt XML format for a device.  If --config is specified the command alters the persistent guest configuration with the device attach taking effect the next time libvirt starts the domain.  For cdrom and floppy devices, this command only replaces the media within an existing device; consider using update-device for this usage.  For passthrough host devices, see also nodedev-detach, needed if the PCI device does not use managed mode.
If --live is specified, affect a running domain.  If --config is specified, affect the next startup 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. When no flag is specified legacy API is used whose behavior depends on the hypervisor driver.
For compatibility purposes, --persistent behaves like --config for an offline domain, and like --live --config for a running domain.
Note: using of partial device definition XML files may lead to unexpected results as some fields may be autogenerated and thus match devices other than expected.
attach-disk Syntax:
attach-disk domain source target [[[--live] [--config] | [--current]] | [--persistent]] [--targetbus bus] [--driver driver] [--subdriver subdriver] [--iothread iothread] [--cache cache] [--io io] [--type type] [--alias alias] [--mode mode] [--sourcetype sourcetype] [--source-protocol protocol] [--source-host-name hostname:port] [--source-host-transport transport] [--source-host-socket socket] [--serial serial] [--wwn wwn] [--rawio] [--address address] [--multifunction] [--print-xml]
Attach a new disk device to the domain.  source is path for the files and devices unless --source-protocol is specified, in which case source is the name of a network disk.  target controls the bus or device under which the disk is exposed to the guest OS. It indicates the "logical" device name; the optional targetbus attribute specifies the type of disk device to emulate; possible values are driver specific, with typical values being ide, scsi, virtio, xen, usb, sata, or sd, if omitted, the bus type is inferred from the style of the device name (e.g.  a device named 'sda' will typically be exported using a SCSI bus).  driver can be file, tap or phy for the Xen hypervisor depending on the kind of access; or qemu for the QEMU emulator.  Further details to the driver can be passed using subdriver. For Xen subdriver can be aio, while for QEMU subdriver should match the format of the disk source, such as raw or qcow2.  Hypervisor default will be used if subdriver is not specified. However, the default may not be correct, esp. for QEMU as for security reasons it is configured not to detect disk formats.  type can indicate lun, cdrom or floppy as alternative to the disk default, although this use only replaces the media within the existing virtual cdrom or floppy device; consider using update-device for this usage instead.  alias can set user supplied alias.  mode can specify the two specific mode readonly or shareable.  sourcetype can indicate the type of source (block|file|network) cache can be one of "default", "none", "writethrough", "writeback", "directsync" or "unsafe".  io controls specific policies on I/O; QEMU guests support "threads", "native" and "io_uring".  iothread is the number within the range of domain IOThreads to which this disk may be attached (QEMU only).  serial is the serial of disk device. wwn is the wwn of disk device.  rawio indicates the disk needs rawio capability.  address is the address of disk device in the form of pci:domain.bus.slot.function, scsi:controller.bus.unit, ide:controller.bus.unit, usb:bus.port, sata:controller.bus.unit or ccw:cssid.ssid.devno. Virtio-ccw devices must have their cssid set to 0xfe.  multifunction indicates specified pci address is a multifunction pci device address.
There is also support for using a network disk. As specified, the user can provide a --source-protocol in which case the source parameter will be interpreted as the source name. --source-protocol must be provided if the user intends to provide a network disk or host information.  Host information can be provided using the tags --source-host-name, --source-host-transport, and --source-host-socket, which respectively denote the name of the host, the host's transport method, and the socket that the host uses. --source-host-socket and --source-host-name cannot both be provided, and the user must provide a --source-host-transport if they want to provide a --source-host-socket.  The --source-host-name parameter supports host:port syntax if the user wants to provide a port as well.
If --print-xml is specified, then the XML of the disk that would be attached is printed instead.
For compatibility purposes, --persistent behaves like --config for an offline domain, and like --live --config for a running domain.  Likewise, --shareable is an alias for --mode shareable.
attach-interface Syntax:
attach-interface domain type source [[[--live] [--config] | [--current]] | [--persistent]] [--target target] [--mac mac] [--script script] [--model model] [--inbound average,peak,burst,floor] [--outbound average,peak,burst] [--alias alias] [--managed] [--print-xml] [--source-mode mode]
Attach a new network interface to the domain.
type can be one of the:
network to indicate connection via a libvirt virtual network,
bridge to indicate connection via a bridge device on the host,
direct to indicate connection directly to one of the host's network interfaces or bridges,
hostdev to indicate connection using a passthrough of PCI device on the host,
vhostuser to indicate connection using a virtio transport protocol.
source indicates the source of the connection.  The source depends on the type of the interface:
network name of the virtual network,
bridge the name of the bridge device,
direct the name of the host's interface or bridge,
hostdev the PCI address of the host's interface formatted as domain:bus:slot.function.
vhostuser the path to UNIX socket (control plane)
--target is used to specify the tap/macvtap device to be used to connect the domain to the source.  Names starting with 'vnet' are considered as auto-generated and are blanked out/regenerated each time the interface is attached.
--mac specifies the MAC address of the network interface; if a MAC address is not given, a new address will be automatically generated (and stored in the persistent configuration if "--config" is given on the command line).
--script is used to specify a path to a custom script to be called while attaching to a bridge - this will be called instead of the default script not in addition to it.  This is valid only for interfaces of bridge type and only for Xen domains.
--model specifies the network device model to be presented to the domain.
alias can set user supplied alias.
--inbound and --outbound control the bandwidth of the interface.  At least one from the average, floor pair must be specified.  The other two peak and burst are optional, so "average,peak", "average,,burst", "average,,,floor", "average" and ",,,floor" are also legal.  Values for average, floor and peak 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.
--managed is usable only for hostdev type and tells libvirt that the interface should be managed, which means detached and reattached from/to the host by libvirt.
--source-mode is mandatory for vhostuser interface and accepts values server and client that control whether hypervisor waits for the other process to connect, or initiates connection, respectively.
If --print-xml is specified, then the XML of the interface that would be attached is printed instead.
If --live is specified, affect a running domain.  If --config is specified, affect the next startup of a persistent guest.  If --current is specified, affect the current domain state, which can either be live or offline.  Both --live and --config flags may be given, but --current is exclusive.  When no flag is specified legacy API is used whose behavior depends on the hypervisor driver.
Note: the optional target value is the name of a device to be created as the back-end on the node.  If not provided a device named "vnetN" or "vifN" will be created automatically.
detach-device Syntax:
detach-device domain FILE [[[--live] [--config] | [--current]] | [--persistent]]
Detach a device from the domain, takes the same kind of XML descriptions as command attach-device.  For passthrough host devices, see also nodedev-reattach, needed if the device does not use managed mode.
Note: The supplied XML description of the device should be as specific as its definition in the domain XML. The set of attributes used to match the device are internal to the drivers. Using a partial definition, or attempting to detach a device that is not present in the domain XML, but shares some specific attributes with one that is present, may lead to unexpected results.
Quirk: Device unplug is asynchronous in most cases and requires guest cooperation. This means that it's up to the discretion of the guest to disallow or delay the unplug arbitrarily. As the libvirt API used in this command was designed as synchronous it returns success after some timeout even if the device was not unplugged yet to allow further interactions with the domain e.g. if the guest is unresponsive. Callers which need to make sure that the device was unplugged can use libvirt events (see virsh event) to be notified when the device is removed. Note that the event may arrive before the command returns.
Note that older versions of virsh used --config as an alias for --persistent.
detach-device-alias Syntax:
detach-device-alias domain alias [[[--live] [--config] | [--current]]]]
Detach a device with given alias from the domain. This command returns successfully after the unplug request was sent to the hypervisor. The actual removal of the device is notified asynchronously via libvirt events (see virsh event).
If --live is specified, affect a running domain.  If --config is specified, affect the next startup 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.
detach-disk Syntax:
detach-disk domain target [[[--live] [--config] | [--current]] | [--persistent]] [--print-xml]
Detach a disk device from a domain. The target is the device as seen from the domain.
If --print-xml is specified, then the XML which would be used to detach the disk is printed instead.
Please see documentation for detach-device for known quirks.
detach-interface Syntax:
detach-interface domain type [--mac mac] [[[--live] [--config] | [--current]] | [--persistent]]
Detach a network interface from a domain.  type can be either network to indicate a physical network device or bridge to indicate a bridge to a device. It is recommended to use the mac option to distinguish between the interfaces if more than one are present on the domain.
update-device Syntax:
update-device domain file [--force] [[[--live] [--config] | [--current]] | [--persistent]]
Update the characteristics of a device associated with domain, based on the device definition in an XML file.  The --force option can be used to force device update, e.g., to eject a CD-ROM even if it is locked/mounted in the domain. See the documentation at https://libvirt.org/formatdomain.html#elementsDevices to learn about libvirt XML format for a device.
If --live is specified, affect a running domain.  If --config is specified, affect the next startup 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. Not specifying any flag is the same as specifying --current.
change-media Syntax:
change-media domain path [--eject] [--insert] [--update] [source] [--force] [[--live] [--config] | [--current]] [--print-xml] [--block]
Change media of CDROM or floppy drive. path can be the fully-qualified path or the unique target name (<target dev='hdc'>) of the disk device. source specifies the path of the media to be inserted or updated. The --block flag allows setting the backing type in case a block device is used as media for the CDROM or floppy drive instead of a file.
--eject indicates the media will be ejected.  --insert indicates the media will be inserted. source must be specified.  If the device has source (e.g. <source file='media'>), and source is not specified, --update is equal to --eject. If the device has no source, and source is specified, --update is equal to --insert. If the device has source, and source is specified, --update behaves like combination of --eject and --insert.  If none of --eject, --insert, and --update is specified, --update is used by default.  The --force option can be used to force media changing.  If --live is specified, alter live configuration of running guest.  If --config is specified, alter persistent configuration, effect observed on next startup of the guest.  --current can be either or both of live and config, depends on the hypervisor's implementation. Both --live and --config flags may be given, but --current is exclusive. If no flag is specified, behavior is different depending on hypervisor. If --print-xml is specified, the XML that would be used to change media is printed instead of changing the media.
The following commands manipulate host devices that are intended to be passed through to guest domains via <hostdev> elements in a domain's <devices> section.  A node device key is generally specified by the bus name followed by its address, using underscores between all components, such as pci_0000_00_02_1, usb_1_5_3, or net_eth1_00_27_13_6a_fe_00.  The nodedev-list gives the full list of host devices that are known to libvirt, although this includes devices that cannot be assigned to a guest (for example, attempting to detach the PCI device that controls the host's hard disk controller where the guest's disk images live could cause the host system to lock up or reboot).
For more information on node device definition see: https://libvirt.org/formatnode.html.
Passthrough devices cannot be simultaneously used by the host and its guest domains, nor by multiple active guests at once.  If the <hostdev> description of a PCI device includes the attribute managed='yes', and the hypervisor driver supports it, then the device is in managed mode, and attempts to use that passthrough device in an active guest will automatically behave as if nodedev-detach (guest start, device hot-plug) and nodedev-reattach (guest stop, device hot-unplug) were called at the right points.  If a PCI device is not marked as managed, then it must manually be detached before guests can use it, and manually reattached to be returned to the host.  Also, if a device is manually detached, then the host does not regain control of the device without a matching reattach, even if the guests use the device in managed mode.
nodedev-create Syntax:
nodedev-create FILE
Create a device on the host node that can then be assigned to virtual machines. Normally, libvirt is able to automatically determine which host nodes are available for use, but this allows registration of host hardware that libvirt did not automatically detect.  file contains xml for a top-level <device> description of a node device.
nodedev-destroy Syntax:
nodedev-destroy device
Destroy (stop) a device on the host. device can be either device name or wwn pair in "wwnn,wwpn" format (only works for vHBA currently).  Note that this makes libvirt quit managing a host device, and may even make that device unusable by the rest of the physical host until a reboot.
nodedev-define Syntax:
nodedev-define FILE
Define an inactive persistent device or modify an existing persistent one from the XML FILE.
nodedev-undefine Syntax:
nodedev-undefine device
Undefine the configuration for a persistent device. If the device is active, make it transient.
nodedev-start Syntax:
nodedev-start network
Start a (previously defined) inactive device.
nodedev-detach Syntax:
nodedev-detach nodedev [--driver backend_driver]