QEMU-QMP-REF(7) | QEMU | QEMU-QMP-REF(7) |
qemu-qmp-ref - QEMU QMP Reference Manual
This document describes all commands currently supported by QMP.
Most of the time their usage is exactly the same as in the user Monitor, this means that any other document which also describe commands (the manpage, QEMU's manual, etc) can and should be consulted.
QMP has two types of commands: regular and query commands. Regular commands usually change the Virtual Machine's state someway, while query commands just return information. The sections below are divided accordingly.
It's important to observe that all communication examples are formatted in a reader-friendly way, so that they're easier to understand. However, in real protocol usage, they're emitted as a single line.
Also, the following notation is used to denote data flow:
Example:
-> data issued by the Client <- Server data response
Please refer to the QEMU Machine Protocol Specification for detailed information on the Server command and response formats.
QEMU error classes
1.2
An enumeration of the I/O operation types
2.1
An enumeration of three options: on, off, and auto
2.2
An enumeration of three values: on, off, and split
2.6
This is a string value or the explicit lack of a string (null pointer in C). Intended for cases when 'optional absent' already has a different meaning.
2.10
An enumeration of options for specifying a PCI BAR
2.12
An enumeration of PCIe link speeds in units of GT/s
4.0
An enumeration of PCIe link width
4.0
Host memory policy types
2.1
Indicates whether a netfilter is attached to a netdev's transmit queue or receive queue or both.
2.5
Key combinations to toggle input-linux between host and guest.
4.0
6.2
The network address family
2.1
Captures a socket address or address range in the Internet namespace.
1.3
Captures a socket address in the local ("Unix socket") namespace.
1.3
Captures a socket address in the vsock namespace.
NOTE:
2.8
A file descriptor name or number.
1.2
1.3
1.3
2.8
1.3
Captures the address of a socket, which could also be a named file descriptor
1.3
Available SocketAddress types
2.9
Captures the address of a socket, which could also be a socket file descriptor
2.9
An enumeration of VM run states.
An enumeration of reasons for a Shutdown.
Information about VM run state
0.14
Query the run status of the VM
StatusInfo reflecting the VM
0.14
Emitted when the virtual machine has shut down, indicating that qemu is about to exit.
NOTE:
0.12
<- { "event": "SHUTDOWN", "data": { "guest": true, "reason": "guest-shutdown" }, "timestamp": { "seconds": 1267040730, "microseconds": 682951 } }
Emitted when the virtual machine is powered down through the power control system, such as via ACPI.
0.12
<- { "event": "POWERDOWN", "timestamp": { "seconds": 1267040730, "microseconds": 682951 } }
Emitted when the virtual machine is reset
0.12
<- { "event": "RESET", "data": { "guest": false, "reason": "guest-reset" }, "timestamp": { "seconds": 1267041653, "microseconds": 9518 } }
Emitted when the virtual machine is stopped
0.12
Emitted when the virtual machine resumes execution
0.12
Emitted when guest enters a hardware suspension state, for example, S3 state, which is sometimes called standby state
1.1
Emitted when guest enters a hardware suspension state with data saved on disk, for example, S4 state, which is sometimes called hibernate state
NOTE:
1.2
<- { "event": "SUSPEND_DISK", "timestamp": { "seconds": 1344456160, "microseconds": 309119 } }
Emitted when the guest has woken up from suspend state and is running
1.1
Emitted when the watchdog device's timer is expired
NOTE:
NOTE:
0.13
<- { "event": "WATCHDOG", "data": { "action": "reset" }, "timestamp": { "seconds": 1267061043, "microseconds": 959568 } }
An enumeration of the actions taken when the watchdog device's timer is expired
2.1
Possible QEMU actions upon guest reboot
6.0
Possible QEMU actions upon guest shutdown
6.0
6.0
Set watchdog action.
2.11
-> { "execute": "watchdog-set-action", "arguments": { "action": "inject-nmi" } } <- { "return": {} }
Set the actions that will be taken by the emulator in response to guest events.
6.0
-> { "execute": "set-action", "arguments": { "reboot": "shutdown", "shutdown" : "pause", "panic": "pause", "watchdog": "inject-nmi" } } <- { "return": {} }
Emitted when guest OS panic is detected
1.5
<- { "event": "GUEST_PANICKED", "data": { "action": "pause" }, "timestamp": { "seconds": 1648245231, "microseconds": 900001 } }
Emitted when guest OS crash loaded is detected
5.0
<- { "event": "GUEST_CRASHLOADED", "data": { "action": "run" }, "timestamp": { "seconds": 1648245259, "microseconds": 893771 } }
Emitted when guest submits a shutdown request via pvpanic interface
9.1
<- { "event": "GUEST_PVSHUTDOWN", "timestamp": { "seconds": 1648245259, "microseconds": 893771 } }
An enumeration of the actions taken when guest OS panic is detected
2.1
An enumeration of the guest panic information types
2.9
Information about a guest panic
2.9
Hyper-V specific guest panic information (HV crash MSRs)
2.9
Reason why the CPU is in a crashed state.
2.12
S390 specific guest panic information (PSW)
2.12
Emitted when a memory failure occurs on host side.
5.2
<- { "event": "MEMORY_FAILURE", "data": { "recipient": "hypervisor", "action": "fatal", "flags": { "action-required": false, "recursive": false } }, "timestamp": { "seconds": 1267061043, "microseconds": 959568 } }
Hardware memory failure occurs, handled by recipient.
5.2
Actions taken by QEMU in response to a hardware memory failure.
5.2
Additional information on memory failures.
5.2
An enumeration of the options specified when enabling notify VM exit
7.2
The type of network endpoint that will be using the credentials. Most types of credential require different setup / structures depending on whether they will be used in a server versus a client.
2.5
The data format that the secret is provided in
2.6
The supported algorithms for computing content digests
2.6
The supported algorithms for content encryption ciphers
2.6
The supported modes for content encryption ciphers
2.6
The supported algorithms for generating initialization vectors for full disk encryption. The 'plain' generator should not be used for disks with sector numbers larger than 2^32, except where compatibility with pre-existing Linux dm-crypt volumes is required.
2.6
The supported full disk encryption formats
2.6
The common options that apply to all full disk encryption formats
2.6
The options that apply to QCow/QCow2 AES-CBC encryption format
2.6
The options that apply to LUKS encryption format
2.6
The options that apply to LUKS encryption format initialization
2.6
The options that are available for all encryption formats when opening an existing volume
2.6
The options that are available for all encryption formats when initializing a new volume
2.6
The common information that applies to all full disk encryption formats
2.7
Information about the LUKS block encryption key slot options
2.7
Information about the LUKS block encryption options
2.7
Information about the block encryption options
2.7
Defines state of keyslots that are affected by the update
5.1
This struct defines the update parameters that activate/de-activate set of keyslots
For keyslot deactivation, this parameter specifies the exact keyslot to deactivate
5.1
The options that are available for all encryption formats when amending encryption settings
5.1
Properties for objects of classes derived from secret-common.
2.6
Properties for secret objects.
Either data or file must be provided, but not both.
2.6
Properties for secret_keyring objects.
5.1
CONFIG_SECRET_KEYRING
Properties for objects of classes derived from tls-creds.
2.5
Properties for tls-creds-anon objects.
2.5
Properties for tls-creds-psk objects.
3.0
Properties for tls-creds-x509 objects.
2.5
The supported algorithms for asymmetric encryption ciphers
7.1
The type of asymmetric keys.
7.1
The padding algorithm for RSA.
7.1
Specific parameters for RSA algorithm.
7.1
The options that are available for all asymmetric key algorithms when creating a new QCryptoAkCipher.
7.1
Type of a background job.
1.7
Indicates the present state of a given job in its lifetime.
2.12
Represents command verbs that can be applied to a job.
2.12
Emitted when a job transitions to a different status.
3.0
Pause an active job.
This command returns immediately after marking the active job for pausing. Pausing an already paused job is an error.
The job will pause as soon as possible, which means transitioning into the PAUSED state if it was RUNNING, or into STANDBY if it was READY. The corresponding JOB_STATUS_CHANGE event will be emitted.
Cancelling a paused job automatically resumes it.
3.0
Resume a paused job.
This command returns immediately after resuming a paused job. Resuming an already running job is an error.
3.0
Instruct an active background job to cancel at the next opportunity. This command returns immediately after marking the active job for cancellation.
The job will cancel as soon as possible and then emit a JOB_STATUS_CHANGE event. Usually, the status will change to ABORTING, but it is possible that a job successfully completes (e.g. because it was almost done and there was no opportunity to cancel earlier than completing the job) and transitions to PENDING instead.
3.0
Manually trigger completion of an active job in the READY state.
3.0
Deletes a job that is in the CONCLUDED state. This command only needs to be run explicitly for jobs that don't have automatic dismiss enabled.
This command will refuse to operate on any job that has not yet reached its terminal state, JOB_STATUS_CONCLUDED. For jobs that make use of JOB_READY event, job-cancel or job-complete will still need to be used as appropriate.
3.0
Instructs all jobs in a transaction (or a single job if it is not part of any transaction) to finalize any graph changes and do any necessary cleanup. This command requires that all involved jobs are in the PENDING state.
For jobs in a transaction, instructing one job to finalize will force ALL jobs in the transaction to finalize, so it is only necessary to instruct a single member job to finalize.
3.0
Information about a job.
The value is a human-readable error message to describe the reason for the job failure. It should not be parsed by applications.
3.0
Return information about jobs.
a list with a JobInfo for each active job
3.0
1.3
2.10
2.10
1.7
1.7
Information about a VMDK extent file
8.0
6.1
8.0
1.7
1.7
6.1
2.7
6.1
8.0
A discriminated record of image format specific information structures.
1.7
Information about a QEMU image file
8.0
Information about a QEMU image file, and potentially its backing image
1.3
Information about all nodes in the block graph starting at some node, annotated with information about that node in relation to its parent.
8.0
Information about all nodes in a block (sub)graph in the form of BlockNodeInfo data. The base BlockNodeInfo struct contains the information for the (sub)graph's root node.
8.0
Information about a QEMU image file check
1.4
Mapping information from a virtual block range to a host file range
2.6
Cache mode information for a block device
2.3
Information about the backing device for a block device.
0.14
An enumeration of block device I/O status.
1.0
Block dirty bitmap information.
1.3
An enumeration of flags that a bitmap can report to the user.
4.0
Qcow2 bitmap information.
4.0
Block latency histogram.
5| * 4| * 3| * * 2| * * * 1| * * * * +------------------ 10 50 100
4.0
Block device information. This structure describes a virtual device and the backing device associated with it.
0.14
Image file size calculation information. This structure describes the size requirements for creating a new image file.
The size requirements depend on the new image file format. File size always equals virtual disk size for the 'raw' format, even for sparse POSIX files. Compact formats such as 'qcow2' represent unallocated and zero regions efficiently so file size may be smaller than virtual disk size.
The values are upper bounds that are guaranteed to fit the new image file. Subsequent modification, such as internal snapshot or further bitmap creation, may require additional space and is not covered here.
2.10
Get a list of BlockInfo for all virtual block devices.
a list of BlockInfo describing each virtual block device. Filter nodes that were created implicitly are skipped over.
0.14
-> { "execute": "query-block" } <- { "return":[ { "io-status": "ok", "device":"ide0-hd0", "locked":false, "removable":false, "inserted":{ "ro":false, "drv":"qcow2", "encrypted":false, "file":"disks/test.qcow2", "backing_file_depth":1, "bps":1000000, "bps_rd":0, "bps_wr":0, "iops":1000000, "iops_rd":0, "iops_wr":0, "bps_max": 8000000, "bps_rd_max": 0, "bps_wr_max": 0, "iops_max": 0, "iops_rd_max": 0, "iops_wr_max": 0, "iops_size": 0, "detect_zeroes": "on", "write_threshold": 0, "image":{ "filename":"disks/test.qcow2", "format":"qcow2", "virtual-size":2048000, "backing_file":"base.qcow2", "full-backing-filename":"disks/base.qcow2", "backing-filename-format":"qcow2", "snapshots":[ { "id": "1", "name": "snapshot1", "vm-state-size": 0, "date-sec": 10000200, "date-nsec": 12, "vm-clock-sec": 206, "vm-clock-nsec": 30 } ], "backing-image":{ "filename":"disks/base.qcow2", "format":"qcow2", "virtual-size":2048000 } } }, "qdev": "ide_disk", "type":"unknown" }, { "io-status": "ok", "device":"ide1-cd0", "locked":false, "removable":true, "qdev": "/machine/unattached/device[23]", "tray_open": false, "type":"unknown" }, { "device":"floppy0", "locked":false, "removable":true, "qdev": "/machine/unattached/device[20]", "type":"unknown" }, { "device":"sd0", "locked":false, "removable":true, "type":"unknown" } ] }
Statistics of a block device during a given interval of time.
2.5
Statistics of a virtual block device or a block backing device.
0.14
File driver statistics
4.2
NVMe driver statistics
5.2
Block driver specific statistics
4.2
Statistics of a virtual block device or a block backing device.
0.14
Query the BlockStats for all virtual block devices.
A list of BlockStats for each virtual block devices.
0.14
-> { "execute": "query-blockstats" } <- { "return":[ { "device":"ide0-hd0", "parent":{ "stats":{ "wr_highest_offset":3686448128, "wr_bytes":9786368, "wr_operations":751, "rd_bytes":122567168, "rd_operations":36772 "wr_total_times_ns":313253456 "rd_total_times_ns":3465673657 "flush_total_times_ns":49653 "flush_operations":61, "rd_merged":0, "wr_merged":0, "idle_time_ns":2953431879, "account_invalid":true, "account_failed":false } }, "stats":{ "wr_highest_offset":2821110784, "wr_bytes":9786368, "wr_operations":692, "rd_bytes":122739200, "rd_operations":36604 "flush_operations":51, "wr_total_times_ns":313253456 "rd_total_times_ns":3465673657 "flush_total_times_ns":49653, "rd_merged":0, "wr_merged":0, "idle_time_ns":2953431879, "account_invalid":true, "account_failed":false }, "qdev": "/machine/unattached/device[23]" }, { "device":"ide1-cd0", "stats":{ "wr_highest_offset":0, "wr_bytes":0, "wr_operations":0, "rd_bytes":0, "rd_operations":0 "flush_operations":0, "wr_total_times_ns":0 "rd_total_times_ns":0 "flush_total_times_ns":0, "rd_merged":0, "wr_merged":0, "account_invalid":false, "account_failed":false }, "qdev": "/machine/unattached/device[24]" }, { "device":"floppy0", "stats":{ "wr_highest_offset":0, "wr_bytes":0, "wr_operations":0, "rd_bytes":0, "rd_operations":0 "flush_operations":0, "wr_total_times_ns":0 "rd_total_times_ns":0 "flush_total_times_ns":0, "rd_merged":0, "wr_merged":0, "account_invalid":false, "account_failed":false }, "qdev": "/machine/unattached/device[16]" }, { "device":"sd0", "stats":{ "wr_highest_offset":0, "wr_bytes":0, "wr_operations":0, "rd_bytes":0, "rd_operations":0 "flush_operations":0, "wr_total_times_ns":0 "rd_total_times_ns":0 "flush_total_times_ns":0, "rd_merged":0, "wr_merged":0, "account_invalid":false, "account_failed":false } } ] }
An enumeration of possible behaviors for errors on I/O operations. The exact meaning depends on whether the I/O was initiated by a guest or by a block job
1.3
An enumeration of possible behaviors for the initial synchronization phase of storage mirroring.
1.3
An enumeration of possible behaviors for the synchronization of a bitmap when used for data copy operations.
4.2
An enumeration whose values tell the mirror block job when to trigger writes to the target.
3.0
Information specific to mirror block jobs.
8.2
Information about a long-running block device operation.
1.1
Return information about long-running block device operations.
a list of BlockJobInfo for each active block job
1.1
Resize a block image while a guest is running.
Either device or node-name must be set but not both.
0.14
-> { "execute": "block_resize", "arguments": { "device": "scratch", "size": 1073741824 } } <- { "return": {} }
An enumeration that tells QEMU how to set the backing file path in a new image file.
1.1
Either device or node-name must be set but not both.
2.5
Optional parameters for backup. These parameters don't affect functionality, but may significantly affect performance.
6.0
NOTE:
4.2
1.6
2.3
Takes a synchronous snapshot of a block device.
0.14
-> { "execute": "blockdev-snapshot-sync", "arguments": { "device": "ide-hd0", "snapshot-file": "/some/place/my-image", "format": "qcow2" } } <- { "return": {} }
Takes a snapshot of a block device.
Take a snapshot, by installing 'node' as the backing image of 'overlay'. Additionally, if 'node' is associated with a block device, the block device changes to using 'overlay' as its new active image.
2.5
-> { "execute": "blockdev-add", "arguments": { "driver": "qcow2", "node-name": "node1534", "file": { "driver": "file", "filename": "hd1.qcow2" }, "backing": null } } <- { "return": {} } -> { "execute": "blockdev-snapshot", "arguments": { "node": "ide-hd0", "overlay": "node1534" } } <- { "return": {} }
Change the backing file in the image file metadata. This does not cause QEMU to reopen the image file to reparse the backing filename (it may, however, perform a reopen to change permissions from r/o -> r/w -> r/o, if needed). The new backing file string is written into the image file metadata, and the QEMU internal strings are updated.
2.1
Live commit of data from overlay image nodes into backing nodes - i.e., writes data between 'top' and 'base' into 'base'.
If top == base, that is an error. If top has no overlays on top of it, or if it is in use by a writer, the job will not be completed by itself. The user needs to complete the job with the block-job-complete command after getting the ready event. (Since 2.0)
If the base image is smaller than top, then the base image will be resized to be the same size as top. If top is smaller than the base image, the base will not be truncated. If you want the base image size to match the size of the smaller top, you can safely truncate it yourself once the commit operation successfully completes.
This filename is not validated. If a pathname string is such that it cannot be resolved by QEMU, that means that subsequent QMP or HMP commands must use node-names for the image in question, as filename lookup methods will fail.
If not specified, QEMU will automatically determine the backing file string to use, or error out if there is no obvious choice. Care should be taken when specifying the string, to specify a valid filename or protocol. (Since 2.1)
1.3
-> { "execute": "block-commit", "arguments": { "device": "virtio0", "top": "/tmp/snap1.qcow2" } } <- { "return": {} }
Start a point-in-time copy of a block device to a new destination. The status of ongoing drive-backup operations can be checked with query-block-jobs where the BlockJobInfo.type field has the value 'backup'. The operation can be stopped before it has completed using the block-job-cancel command.
1.6
-> { "execute": "drive-backup", "arguments": { "device": "drive0", "sync": "full", "target": "backup.img" } } <- { "return": {} }
Start a point-in-time copy of a block device to a new destination. The status of ongoing blockdev-backup operations can be checked with query-block-jobs where the BlockJobInfo.type field has the value 'backup'. The operation can be stopped before it has completed using the block-job-cancel command.
2.3
-> { "execute": "blockdev-backup", "arguments": { "device": "src-id", "sync": "full", "target": "tgt-id" } } <- { "return": {} }
Get the named block driver list
the list of BlockDeviceInfo
2.0
-> { "execute": "query-named-block-nodes" } <- { "return": [ { "ro":false, "drv":"qcow2", "encrypted":false, "file":"disks/test.qcow2", "node-name": "my-node", "backing_file_depth":1, "detect_zeroes":"off", "bps":1000000, "bps_rd":0, "bps_wr":0, "iops":1000000, "iops_rd":0, "iops_wr":0, "bps_max": 8000000, "bps_rd_max": 0, "bps_wr_max": 0, "iops_max": 0, "iops_rd_max": 0, "iops_wr_max": 0, "iops_size": 0, "write_threshold": 0, "image":{ "filename":"disks/test.qcow2", "format":"qcow2", "virtual-size":2048000, "backing_file":"base.qcow2", "full-backing-filename":"disks/base.qcow2", "backing-filename-format":"qcow2", "snapshots":[ { "id": "1", "name": "snapshot1", "vm-state-size": 0, "date-sec": 10000200, "date-nsec": 12, "vm-clock-sec": 206, "vm-clock-nsec": 30 } ], "backing-image":{ "filename":"disks/base.qcow2", "format":"qcow2", "virtual-size":2048000 } } } ] }
4.0
4.0
Enum of base block permissions.
4.0
Block Graph edge description for x-debug-query-block-graph.
4.0
Block Graph - list of nodes and list of edges.
4.0
Get the block graph.
4.0
Start mirroring a block device's writes to a new destination. target specifies the target of the new image. If the file exists, or if it is a device, it will be used as the new destination for writes. If it does not exist, a new file will be created. format specifies the format of the mirror image, default is to probe if mode='existing', else the format of the source.
1.3
-> { "execute": "drive-mirror", "arguments": { "device": "ide-hd0", "target": "/some/place/my-image", "sync": "full", "format": "qcow2" } } <- { "return": {} }
A set of parameters describing drive mirror setup.
1.3
2.4
2.4
4.1
4.0
Create a dirty bitmap with a name on the node, and start tracking the writes.
2.4
-> { "execute": "block-dirty-bitmap-add", "arguments": { "node": "drive0", "name": "bitmap0" } } <- { "return": {} }
Stop write tracking and remove the dirty bitmap that was created with block-dirty-bitmap-add. If the bitmap is persistent, remove it from its storage too.
2.4
-> { "execute": "block-dirty-bitmap-remove", "arguments": { "node": "drive0", "name": "bitmap0" } } <- { "return": {} }
Clear (reset) a dirty bitmap on the device, so that an incremental backup from this point in time forward will only backup clusters modified after this clear operation.
2.4
-> { "execute": "block-dirty-bitmap-clear", "arguments": { "node": "drive0", "name": "bitmap0" } } <- { "return": {} }
Enables a dirty bitmap so that it will begin tracking disk changes.
4.0
-> { "execute": "block-dirty-bitmap-enable", "arguments": { "node": "drive0", "name": "bitmap0" } } <- { "return": {} }
Disables a dirty bitmap so that it will stop tracking disk changes.
4.0
-> { "execute": "block-dirty-bitmap-disable", "arguments": { "node": "drive0", "name": "bitmap0" } } <- { "return": {} }
Merge dirty bitmaps listed in bitmaps to the target dirty bitmap. Dirty bitmaps in bitmaps will be unchanged, except if it also appears as the target bitmap. Any bits already set in target will still be set after the merge, i.e., this operation does not clear the target. On error, target is unchanged.
The resulting bitmap will count as dirty any clusters that were dirty in any of the source bitmaps. This can be used to achieve backup checkpoints, or in simpler usages, to copy bitmaps.
4.0
-> { "execute": "block-dirty-bitmap-merge", "arguments": { "node": "drive0", "target": "bitmap0", "bitmaps": ["bitmap1"] } } <- { "return": {} }
SHA256 hash of dirty bitmap data
2.10
Get bitmap SHA256.
BlockDirtyBitmapSha256
2.10
Start mirroring a block device's writes to a new destination.
2.6
-> { "execute": "blockdev-mirror", "arguments": { "device": "ide-hd0", "target": "target0", "sync": "full" } } <- { "return": {} }
A set of parameters describing block throttling.
1.1
Limit parameters for throttling. Since some limit combinations are illegal, limits should always be set in one transaction. All fields are optional. When setting limits, if a field is missing the current value is not changed.
2.11
Properties for throttle-group objects.
2.11
Copy data from a backing file into a block device.
The block streaming operation is performed in the background until the entire backing file has been copied. This command returns immediately once streaming has started. The status of ongoing block streaming operations can be checked with query-block-jobs. The operation can be stopped before it has completed using the block-job-cancel command.
The node that receives the data is called the top image, can be located in any part of the chain (but always above the base image; see below) and can be specified using its device or node name. Earlier qemu versions only allowed 'device' to name the top level node; presence of the 'base-node' parameter during introspection can be used as a witness of the enhanced semantics of 'device'.
If a base file is specified then sectors are not copied from that base file and its backing chain. This can be used to stream a subset of the backing file chain instead of flattening the entire image. When streaming completes the image file will have the base file as its backing file, unless that node was changed while the job was running. In that case, base's parent's backing (or filtered, whichever exists) child (i.e., base at the beginning of the job) will be the new backing file.
On successful completion the image file is updated to drop the backing file and the BLOCK_JOB_COMPLETED event is emitted.
In case device is a filter node, block-stream modifies the first non-filter overlay node below it to point to the new backing node instead of modifying device itself.
If a pathname string is such that it cannot be resolved by QEMU, that means that subsequent QMP or HMP commands must use node-names for the image in question, as filename lookup methods will fail.
If not specified, QEMU will automatically determine the backing file string to use, or error out if there is no obvious choice. Care should be taken when specifying the string, to specify a valid filename or protocol. (Since 2.1)
1.1
-> { "execute": "block-stream", "arguments": { "device": "virtio0", "base": "/tmp/master.qcow2" } } <- { "return": {} }
Set maximum speed for a background block operation.
This command can only be issued when there is an active block job.
Throttling can be disabled by setting the speed to 0.
1.1
Stop an active background block operation.
This command returns immediately after marking the active background block operation for cancellation. It is an error to call this command if no operation is in progress.
The operation will cancel as soon as possible and then emit the BLOCK_JOB_CANCELLED event. Before that happens the job is still visible when enumerated using query-block-jobs.
Note that if you issue 'block-job-cancel' after 'drive-mirror' has indicated (via the event BLOCK_JOB_READY) that the source and destination are synchronized, then the event triggered by this command changes to BLOCK_JOB_COMPLETED, to indicate that the mirroring has ended and the destination now has a point-in-time copy tied to the time of the cancellation.
For streaming, the image file retains its backing file unless the streaming operation happens to complete just as it is being cancelled. A new streaming operation can be started at a later time to finish copying all data from the backing file.
1.1
Pause an active background block operation.
This command returns immediately after marking the active background block operation for pausing. It is an error to call this command if no operation is in progress or if the job is already paused.
The operation will pause as soon as possible. No event is emitted when the operation is actually paused. Cancelling a paused job automatically resumes it.
1.3
Resume an active background block operation.
This command returns immediately after resuming a paused background block operation. It is an error to call this command if no operation is in progress or if the job is not paused.
This command also clears the error status of the job.
1.3
Manually trigger completion of an active background block operation. This is supported for drive mirroring, where it also switches the device to write to the target path only. The ability to complete is signaled with a BLOCK_JOB_READY event.
This command completes an active background block operation synchronously. The ordering of this command's return with the BLOCK_JOB_COMPLETED event is not defined. Note that if an I/O error occurs during the processing of this command: 1) the command itself will fail; 2) the error will be processed according to the rerror/werror arguments that were specified when starting the operation.
A cancelled or paused job cannot be completed.
1.3
For jobs that have already concluded, remove them from the block-job-query list. This command only needs to be run for jobs which were started with QEMU 2.12+ job lifetime management semantics.
This command will refuse to operate on any job that has not yet reached its terminal state, JOB_STATUS_CONCLUDED. For jobs that make use of the BLOCK_JOB_READY event, block-job-cancel or block-job-complete will still need to be used as appropriate.
2.12
Once a job that has manual=true reaches the pending state, it can be instructed to finalize any graph changes and do any necessary cleanup via this command. For jobs in a transaction, instructing one job to finalize will force ALL jobs in the transaction to finalize, so it is only necessary to instruct a single member job to finalize.
2.12
8.2
Block job options that can be changed after job creation.
8.2
Change the block job's options.
8.2
Determines how to handle discard requests.
2.9
Describes the operation mode for the automatic conversion of plain zero writes by the OS to driver specific optimized zero write commands.
2.1
Selects the AIO backend to handle I/O requests
2.9
Includes cache-related options for block devices
2.9
Drivers that are supported in block device operations.
2.9
Driver specific block device options for the file backend.
2.9
Driver specific block device options for the null backend.
2.9
Driver specific block device options for the NVMe backend.
Note that the PCI device must have been unbound from any host kernel driver before instructing QEMU to add the blockdev.
2.12
Driver specific block device options for the vvfat protocol.
2.9
Driver specific block device options for image format that have no option besides their data source.
2.9
Driver specific block device options for LUKS.
2.9
Driver specific block device options for image format that have no option besides their data source and an optional backing file.
2.9
General overlap check modes.
2.9
Structure of flags for each metadata structure. Setting a field to 'true' makes QEMU guard that Qcow2 format structure against unintended overwriting. See Qcow2 format specification for detailed information on these structures. The default value is chosen according to the template given.
2.9
Specifies which metadata structures should be guarded against unintended overwriting.
2.9
2.10
2.10
Driver specific block device options for qcow.
2.10
2.10
2.10
Filter driver intended to be inserted between format and protocol node and do preallocation in protocol node on write.
6.0
Driver specific block device options for qcow2.
2.9
2.12
2.12
2.12
2.12
2.9
Trigger events supported by blkdebug.
2.9
Kinds of I/O that blkdebug can inject errors in.
4.1
Describes a single error injection for blkdebug.
2.9
Describes a single state-change event for blkdebug.
2.9
Driver specific block device options for blkdebug.
2.9
Driver specific block device options for blklogwrites.
3.0
Driver specific block device options for blkverify.
2.9
Driver specific block device options for blkreplay.
4.2
An enumeration of quorum read patterns.
2.9
Driver specific block device options for Quorum
2.9
Driver specific block device options for Gluster
2.9
Driver specific block device options for the io_uring backend.
7.2
CONFIG_BLKIO
Driver specific block device options for the nvme-io_uring backend.
7.2
CONFIG_BLKIO
Driver specific block device options for the virtio-blk-vfio-pci backend.
7.2
CONFIG_BLKIO
Driver specific block device options for the virtio-blk-vhost-user backend.
7.2
CONFIG_BLKIO
Driver specific block device options for the virtio-blk-vhost-vdpa backend.
7.2
CONFIG_BLKIO
An enumeration of libiscsi transport types
2.9
An enumeration of header digests supported by libiscsi
2.9
Driver specific block device options for iscsi
2.9
3.0
6.1
6.1
6.1
6.1
6.1
8.0
6.1
6.1
6.1
6.1
2.9
An enumeration of replication modes.
2.9
CONFIG_REPLICATION
Driver specific block device options for replication
2.9
CONFIG_REPLICATION
An enumeration of NFS transport types
2.9
Captures the address of the socket
2.9
Driver specific block device option for NFS
2.9
Driver specific block device options shared by all protocols supported by the curl backend.
2.9
Driver specific block device options for HTTP connections over the curl backend. URLs must start with "http://".
2.9
Driver specific block device options for HTTPS connections over the curl backend. URLs must start with "https://".
2.9
Driver specific block device options for FTP connections over the curl backend. URLs must start with "ftp://".
2.9
Driver specific block device options for FTPS connections over the curl backend. URLs must start with "ftps://".
2.9
Driver specific block device options for NBD.
2.9
Driver specific block device options for the raw driver.
2.9
Driver specific block device options for the throttle driver
2.11
Driver specific block device options for the copy-on-read driver.
6.0
An enumeration of possible behaviors for copy-before-write operation failures.
7.1
Driver specific block device options for the copy-before-write driver, which does so called copy-before-write operations: when data is written to the filter, the filter first reads corresponding blocks from its file child and copies them to target child. After successfully copying, the write request is propagated to file child. If copying fails, the original write request is failed too and no data is written to file child.
6.2
Options for creating a block device. Many options are available for all block devices, independent of the block driver:
2.9
Reference to a block device.
2.9
Reference to a block device.
2.9
Creates a new block device.
2.9
-> { "execute": "blockdev-add", "arguments": { "driver": "qcow2", "node-name": "test1", "file": { "driver": "file", "filename": "test.qcow2" } } } <- { "return": {} }
-> { "execute": "blockdev-add", "arguments": { "driver": "qcow2", "node-name": "node0", "discard": "unmap", "cache": { "direct": true }, "file": { "driver": "file", "filename": "/tmp/test.qcow2" }, "backing": { "driver": "raw", "file": { "driver": "file", "filename": "/dev/fdset/4" } } } } <- { "return": {} }
Reopens one or more block devices using the given set of options. Any option not specified will be reset to its default value regardless of its previous status. If an option cannot be changed or a particular driver does not support reopening then the command will return an error. All devices in the list are reopened in one transaction, so if one of them fails then the whole transaction is cancelled.
The command receives a list of block devices to reopen. For each one of them, the top-level node-name option (from BlockdevOptions) must be specified and is used to select the block device to be reopened. Other node-name options must be either omitted or set to the current name of the appropriate node. This command won't change any node name and any attempt to do it will result in an error.
In the case of options that refer to child nodes, the behavior of this command depends on the value:
Options (1) and (2) are supported in all cases. Option (3) is supported for file and backing, and option (4) for backing only.
Unlike with blockdev-add, the backing option must always be present unless the node being reopened does not have a backing file and its image does not have a default backing file name as part of its metadata.
6.1
Deletes a block device that has been added using blockdev-add. The command will fail if the node is attached to a device or is otherwise being used.
2.9
-> { "execute": "blockdev-add", "arguments": { "driver": "qcow2", "node-name": "node0", "file": { "driver": "file", "filename": "test.qcow2" } } } <- { "return": {} } -> { "execute": "blockdev-del", "arguments": { "node-name": "node0" } } <- { "return": {} }
Driver specific image creation options for file.
2.12
Driver specific image creation options for gluster.
2.12
Driver specific image creation options for LUKS.
2.12
Driver specific image creation options for NFS.
2.12
Driver specific image creation options for parallels.
2.12
Driver specific image creation options for qcow.
2.12
2.12
Compression type used in qcow2 image file
5.1
Driver specific image creation options for qcow2.
2.12
Driver specific image creation options for qed.
2.12
Driver specific image creation options for rbd/Ceph.
2.12
Subformat options for VMDK images
4.0
Adapter type info for VMDK images
4.0
Driver specific image creation options for VMDK.
4.0
Driver specific image creation options for SSH.
2.12
Driver specific image creation options for VDI.
2.12
2.12
Driver specific image creation options for vhdx.
2.12
2.12
Driver specific image creation options for vpc (VHD).
2.12
Options for creating an image format on a given node.
2.12
Starts a job to create an image format on a given node. The job is automatically finalized, but a manual job-dismiss is required.
3.0
Driver specific image amend options for LUKS.
5.1
Driver specific image amend options for qcow2. For now, only encryption options can be amended
5.1
Options for amending an image format
5.1
Starts a job to amend format specific options of an existing open block device The job is automatically finalized, but a manual job-dismiss is required.
5.1
An enumeration of action that has been taken when a DISK I/O occurs
2.1
Emitted when a disk image is being marked corrupt. The image can be identified by its device or node name. The 'device' field is always present for compatibility reasons, but it can be empty ("") if the image does not have a device name associated.
NOTE:
<- { "event": "BLOCK_IMAGE_CORRUPTED", "data": { "device": "", "node-name": "drive", "fatal": false, "msg": "L2 table offset 0x2a2a2a00 unaligned (L1 index: 0)" }, "timestamp": { "seconds": 1648243240, "microseconds": 906060 } }
1.7
Emitted when a disk I/O error occurs
NOTE:
NOTE:
0.13
<- { "event": "BLOCK_IO_ERROR", "data": { "qom-path": "/machine/unattached/device[0]", "device": "ide0-hd1", "node-name": "#block212", "operation": "write", "action": "stop", "reason": "No space left on device" }, "timestamp": { "seconds": 1265044230, "microseconds": 450486 } }
Emitted when a block job has completed
1.1
<- { "event": "BLOCK_JOB_COMPLETED", "data": { "type": "stream", "device": "virtio-disk0", "len": 10737418240, "offset": 10737418240, "speed": 0 }, "timestamp": { "seconds": 1267061043, "microseconds": 959568 } }
Emitted when a block job has been cancelled
1.1
<- { "event": "BLOCK_JOB_CANCELLED", "data": { "type": "stream", "device": "virtio-disk0", "len": 10737418240, "offset": 134217728, "speed": 0 }, "timestamp": { "seconds": 1267061043, "microseconds": 959568 } }
Emitted when a block job encounters an error
1.3
<- { "event": "BLOCK_JOB_ERROR", "data": { "device": "ide0-hd1", "operation": "write", "action": "stop" }, "timestamp": { "seconds": 1265044230, "microseconds": 450486 } }
Emitted when a block job is ready to complete
NOTE:
1.3
<- { "event": "BLOCK_JOB_READY", "data": { "device": "drive0", "type": "mirror", "speed": 0, "len": 2097152, "offset": 2097152 }, "timestamp": { "seconds": 1265044230, "microseconds": 450486 } }
Emitted when a block job is awaiting explicit authorization to finalize graph changes via block-job-finalize. If this job is part of a transaction, it will not emit this event until the transaction has converged first.
2.12
<- { "event": "BLOCK_JOB_PENDING", "data": { "type": "mirror", "id": "backup_1" }, "timestamp": { "seconds": 1265044230, "microseconds": 450486 } }
Preallocation mode of QEMU image file
2.2
Emitted when writes on block device reaches or exceeds the configured write threshold. For thin-provisioned devices, this means the device should be extended to avoid pausing for disk exhaustion. The event is one shot. Once triggered, it needs to be re-registered with another block-set-write-threshold command.
2.3
Change the write threshold for a block drive. An event will be delivered if a write to this block drive crosses the configured threshold. The threshold is an offset, thus must be non-negative. Default is no write threshold. Setting the threshold to zero disables it.
This is useful to transparently resize thin-provisioned drives without the guest OS noticing.
2.3
-> { "execute": "block-set-write-threshold", "arguments": { "node-name": "mydev", "write-threshold": 17179869184 } } <- { "return": {} }
Dynamically reconfigure the block driver state graph. It can be used to add, remove, insert or replace a graph node. Currently only the Quorum driver implements this feature to add or remove its child. This is useful to fix a broken quorum child.
If node is specified, it will be inserted under parent. child may not be specified in this case. If both parent and child are specified but node is not, child will be detached from parent.
FIXME Removing children from a quorum node means introducing gaps in the child indices. This cannot be represented in the 'children' list of BlockdevOptionsQuorum, as returned by .bdrv_refresh_filename().
Warning: The data in a new quorum child MUST be consistent with that of the rest of the array.
2.7
-> { "execute": "blockdev-add", "arguments": { "driver": "raw", "node-name": "new_node", "file": { "driver": "file", "filename": "test.raw" } } } <- { "return": {} } -> { "execute": "x-blockdev-change", "arguments": { "parent": "disk1", "node": "new_node" } } <- { "return": {} }
-> { "execute": "x-blockdev-change", "arguments": { "parent": "disk1", "child": "children.1" } } <- { "return": {} }
Move node and its children into the iothread. If iothread is null then move node and its children into the main loop.
The node must not be attached to a BlockBackend.
2.12
-> { "execute": "x-blockdev-set-iothread", "arguments": { "node-name": "disk1", "iothread": "iothread0" } } <- { "return": {} }
-> { "execute": "x-blockdev-set-iothread", "arguments": { "node-name": "disk1", "iothread": null } } <- { "return": {} }
An enumeration of the quorum operation types
2.6
Emitted by the Quorum block driver if it fails to establish a quorum
NOTE:
2.0
<- { "event": "QUORUM_FAILURE", "data": { "reference": "usr1", "sector-num": 345435, "sectors-count": 5 }, "timestamp": { "seconds": 1344522075, "microseconds": 745528 } }
Emitted to report a corruption of a Quorum file
NOTE:
2.0
<- { "event": "QUORUM_REPORT_BAD", "data": { "node-name": "node0", "sector-num": 345435, "sectors-count": 5, "type": "read" }, "timestamp": { "seconds": 1344522075, "microseconds": 745528 } }
<- { "event": "QUORUM_REPORT_BAD", "data": { "node-name": "node0", "sector-num": 0, "sectors-count": 2097120, "type": "flush", "error": "Broken pipe" }, "timestamp": { "seconds": 1456406829, "microseconds": 291763 } }
1.7
Synchronously take an internal snapshot of a block device, when the format of the image used supports it. If the name is an empty string, or a snapshot with name already exists, the operation will fail.
NOTE:
1.7
-> { "execute": "blockdev-snapshot-internal-sync", "arguments": { "device": "ide-hd0", "name": "snapshot0" } } <- { "return": {} }
Synchronously delete an internal snapshot of a block device, when the format of the image used support it. The snapshot is identified by name or id or both. One of the name or id is required. Return SnapshotInfo for the successfully deleted snapshot.
SnapshotInfo
1.7
-> { "execute": "blockdev-snapshot-delete-internal-sync", "arguments": { "device": "ide-hd0", "name": "snapshot0" } } <- { "return": { "id": "1", "name": "snapshot0", "vm-state-size": 0, "date-sec": 1000012, "date-nsec": 10, "vm-clock-sec": 100, "vm-clock-nsec": 20, "icount": 220414 } }
Not used by QMP; hack to let us use BlockGraphInfoList internally
8.0
Policy that BIOS should use to interpret cylinder/head/sector addresses. Note that Bochs BIOS and SeaBIOS will not actually translate logical CHS to physical; instead, they will use logical block addressing.
2.0
Type of Floppy drive to be emulated by the Floppy Disk Controller.
2.6
Information about a persistent reservation manager
3.0
Returns a list of information about each persistent reservation manager.
a list of PRManagerInfo for each persistent reservation manager
3.0
Ejects the medium from a removable drive.
NOTE:
0.14
Opens a block device's tray. If there is a block driver state tree inserted as a medium, it will become inaccessible to the guest (but it will remain associated to the block device, so closing the tray will make it accessible again).
If the tray was already open before, this will be a no-op.
Once the tray opens, a DEVICE_TRAY_MOVED event is emitted. There are cases in which no such event will be generated, these include:
2.5
-> { "execute": "blockdev-open-tray", "arguments": { "id": "ide0-1-0" } } <- { "timestamp": { "seconds": 1418751016, "microseconds": 716996 }, "event": "DEVICE_TRAY_MOVED", "data": { "device": "ide1-cd0", "id": "ide0-1-0", "tray-open": true } } <- { "return": {} }
Closes a block device's tray. If there is a block driver state tree associated with the block device (which is currently ejected), that tree will be loaded as the medium.
If the tray was already closed before, this will be a no-op.
2.5
-> { "execute": "blockdev-close-tray", "arguments": { "id": "ide0-1-0" } } <- { "timestamp": { "seconds": 1418751345, "microseconds": 272147 }, "event": "DEVICE_TRAY_MOVED", "data": { "device": "ide1-cd0", "id": "ide0-1-0", "tray-open": false } } <- { "return": {} }
Removes a medium (a block driver state tree) from a block device. That block device's tray must currently be open (unless there is no attached guest device).
If the tray is open and there is no medium inserted, this will be a no-op.
2.12
-> { "execute": "blockdev-remove-medium", "arguments": { "id": "ide0-1-0" } } <- { "error": { "class": "GenericError", "desc": "Tray of device 'ide0-1-0' is not open" } } -> { "execute": "blockdev-open-tray", "arguments": { "id": "ide0-1-0" } } <- { "timestamp": { "seconds": 1418751627, "microseconds": 549958 }, "event": "DEVICE_TRAY_MOVED", "data": { "device": "ide1-cd0", "id": "ide0-1-0", "tray-open": true } } <- { "return": {} } -> { "execute": "blockdev-remove-medium", "arguments": { "id": "ide0-1-0" } } <- { "return": {} }
Inserts a medium (a block driver state tree) into a block device. That block device's tray must currently be open (unless there is no attached guest device) and there must be no medium inserted already.
2.12
-> { "execute": "blockdev-add", "arguments": { "node-name": "node0", "driver": "raw", "file": { "driver": "file", "filename": "fedora.iso" } } } <- { "return": {} } -> { "execute": "blockdev-insert-medium", "arguments": { "id": "ide0-1-0", "node-name": "node0" } } <- { "return": {} }
Specifies the new read-only mode of a block device subject to the blockdev-change-medium command.
2.3
Changes the medium inserted into a block device by ejecting the current medium and loading a new image file which is inserted as the new medium (this command combines blockdev-open-tray, blockdev-remove-medium, blockdev-insert-medium and blockdev-close-tray).
2.5
-> { "execute": "blockdev-change-medium", "arguments": { "id": "ide0-1-0", "filename": "/srv/images/Fedora-12-x86_64-DVD.iso", "format": "raw" } } <- { "return": {} }
-> { "execute": "blockdev-change-medium", "arguments": { "id": "floppyA", "filename": "/srv/images/ro.img", "format": "raw", "read-only-mode": "retain" } } <- { "error": { "class": "GenericError", "desc": "Could not open '/srv/images/ro.img': Permission denied" } } -> { "execute": "blockdev-change-medium", "arguments": { "id": "floppyA", "filename": "/srv/images/ro.img", "format": "raw", "read-only-mode": "read-only" } } <- { "return": {} }
Emitted whenever the tray of a removable device is moved by the guest or by HMP/QMP commands
1.1
<- { "event": "DEVICE_TRAY_MOVED", "data": { "device": "ide1-cd0", "id": "/machine/unattached/device[22]", "tray-open": true }, "timestamp": { "seconds": 1265044230, "microseconds": 450486 } }
Emitted whenever the connected status of a persistent reservation manager changes.
3.0
<- { "event": "PR_MANAGER_STATUS_CHANGED", "data": { "id": "pr-helper0", "connected": true }, "timestamp": { "seconds": 1519840375, "microseconds": 450486 } }
Change I/O throttle limits for a block drive.
Since QEMU 2.4, each device with I/O limits is member of a throttle group.
If two or more devices are members of the same group, the limits will apply to the combined I/O of the whole group in a round-robin fashion. Therefore, setting new I/O limits to a device will affect the whole group.
The name of the group can be specified using the 'group' parameter. If the parameter is unset, it is assumed to be the current group of that device. If it's not in any group yet, the name of the device will be used as the name for its group.
The 'group' parameter can also be used to move a device to a different group. In this case the limits specified in the parameters will be applied to the new group only.
I/O limits can be disabled by setting all of them to 0. In this case the device will be removed from its group and the rest of its members will not be affected. The 'group' parameter is ignored.
1.1
-> { "execute": "block_set_io_throttle", "arguments": { "id": "virtio-blk-pci0/virtio-backend", "bps": 0, "bps_rd": 0, "bps_wr": 0, "iops": 512, "iops_rd": 0, "iops_wr": 0, "bps_max": 0, "bps_rd_max": 0, "bps_wr_max": 0, "iops_max": 0, "iops_rd_max": 0, "iops_wr_max": 0, "bps_max_length": 0, "iops_size": 0 } } <- { "return": {} }
-> { "execute": "block_set_io_throttle", "arguments": { "id": "ide0-1-0", "bps": 1000000, "bps_rd": 0, "bps_wr": 0, "iops": 0, "iops_rd": 0, "iops_wr": 0, "bps_max": 8000000, "bps_rd_max": 0, "bps_wr_max": 0, "iops_max": 0, "iops_rd_max": 0, "iops_wr_max": 0, "bps_max_length": 60, "iops_size": 0 } } <- { "return": {} }
Manage read, write and flush latency histograms for the device.
If only id parameter is specified, remove all present latency histograms for the device. Otherwise, add/reset some of (or all) latency histograms.
4.0
Set new histograms for all io types with intervals [0, 10), [10, 50), [50, 100), [100, +inf):
-> { "execute": "block-latency-histogram-set", "arguments": { "id": "drive0", "boundaries": [10, 50, 100] } } <- { "return": {} }
Set new histogram only for write, other histograms will remain not changed (or not created):
-> { "execute": "block-latency-histogram-set", "arguments": { "id": "drive0", "boundaries-write": [10, 50, 100] } } <- { "return": {} }
Set new histograms with the following intervals:
-> { "execute": "block-latency-histogram-set", "arguments": { "id": "drive0", "boundaries": [10, 50, 100], "boundaries-write": [1000, 5000] } } <- { "return": {} }
Remove all latency histograms:
-> { "execute": "block-latency-histogram-set", "arguments": { "id": "drive0" } } <- { "return": {} }
Keep this type consistent with the nbd-server-start arguments. The only intended difference is using SocketAddress instead of SocketAddressLegacy.
4.2
Start an NBD server listening on the given host and port. Block devices can then be exported using nbd-server-add. The NBD server will present them as named exports; for example, another QEMU instance could refer to them as "nbd:HOST:PORT:exportname=NAME".
Keep this type consistent with the NbdServerOptions type. The only intended difference is using SocketAddressLegacy instead of SocketAddress.
1.3
An NBD block export (common options shared between nbd-server-add and the NBD branch of block-export-add).
5.0
An NBD block export (distinct options used in the NBD branch of block-export-add).
5.2
A vhost-user-blk block export.
5.2
Possible allow_other modes for FUSE exports.
6.1
Options for exporting a block graph node on some (file) mountpoint as a raw image.
6.0
CONFIG_FUSE
A vduse-blk block export.
7.1
An NBD block export, per legacy nbd-server-add command.
5.0
Export a block node to QEMU's embedded NBD server.
The export name will be used as the id for the resulting block export.
1.3
Mode for removing a block export.
2.12
Remove NBD export by name.
2.12
Stop QEMU's embedded NBD server, and unregister all devices previously added via nbd-server-add.
1.3
An enumeration of block export types
4.2
Describes a block export, i.e. how single node should be exported on an external interface.
4.2
Creates a new block export.
5.2
Request to remove a block export. This drops the user's reference to the export, but the export may still stay around after this command returns until the shutdown of the export has completed.
5.2
Emitted when a block export is removed and its id can be reused.
5.2
Information about a single block export.
5.2
A list of BlockExportInfo describing all block exports
5.2
Information about a character device.
NOTE:
0.14
Returns information about current character devices.
a list of ChardevInfo
0.14
-> { "execute": "query-chardev" } <- { "return": [ { "label": "charchannel0", "filename": "unix:/var/lib/libvirt/qemu/seabios.rhel6.agent,server=on", "frontend-open": false }, { "label": "charmonitor", "filename": "unix:/var/lib/libvirt/qemu/seabios.rhel6.monitor,server=on", "frontend-open": true }, { "label": "charserial0", "filename": "pty:/dev/pts/2", "frontend-open": true } ] }
Information about a character device backend
2.0
Returns information about character device backends.
a list of ChardevBackendInfo
2.0
-> { "execute": "query-chardev-backends" } <- { "return":[ { "name":"udp" }, { "name":"tcp" }, { "name":"unix" }, { "name":"spiceport" } ] }
An enumeration of data format.
1.4
Write to a ring buffer character device.
1.4
-> { "execute": "ringbuf-write", "arguments": { "device": "foo", "data": "abcdefgh", "format": "utf8" } } <- { "return": {} }
Read from a ring buffer character device.
data read from the device
1.4
-> { "execute": "ringbuf-read", "arguments": { "device": "foo", "size": 1000, "format": "utf8" } } <- { "return": "abcdefgh" }
Configuration shared across all chardev backends
2.6
Configuration info for file chardevs.
1.4
Configuration info for device and pipe chardevs.
1.4
Configuration info for (stream) socket chardevs.
1.4
Configuration info for datagram socket chardevs.
1.5
Configuration info for mux chardevs.
1.5
Configuration info for stdio chardevs.
1.5
Configuration info for spice vm channel chardevs.
1.5
CONFIG_SPICE
Configuration info for spice port chardevs.
1.5
CONFIG_SPICE
Configuration info for DBus chardevs.
7.0
CONFIG_DBUS_DISPLAY
Configuration info for virtual console chardevs.
NOTE:
1.5
Configuration info for ring buffer chardevs.
1.5
Configuration info for qemu vdagent implementation.
6.1
CONFIG_SPICE_PROTOCOL
Configuration info for pty implementation.
9.2
1.4
1.4
1.4
1.4
1.5
2.6
1.5
1.5
1.5
CONFIG_SPICE
1.5
CONFIG_SPICE
6.1
CONFIG_SPICE_PROTOCOL
7.0
CONFIG_DBUS_DISPLAY
1.5
1.5
9.2
Configuration info for the new chardev backend.
1.4
Return info about the chardev backend just created.
1.4
Add a character device backend
ChardevReturn.
1.4
-> { "execute" : "chardev-add", "arguments" : { "id" : "foo", "backend" : { "type" : "null", "data" : {} } } } <- { "return": {} }
-> { "execute" : "chardev-add", "arguments" : { "id" : "bar", "backend" : { "type" : "file", "data" : { "out" : "/tmp/bar.log" } } } } <- { "return": {} }
-> { "execute" : "chardev-add", "arguments" : { "id" : "baz", "backend" : { "type" : "pty", "data" : {} } } } <- { "return": { "pty" : "/dev/pty/42" } }
Change a character device backend
ChardevReturn.
2.10
-> { "execute" : "chardev-change", "arguments" : { "id" : "baz", "backend" : { "type" : "pty", "data" : {} } } } <- { "return": { "pty" : "/dev/pty/42" } }
-> {"execute" : "chardev-change", "arguments" : { "id" : "charchannel2", "backend" : { "type" : "socket", "data" : { "addr" : { "type" : "unix" , "data" : { "path" : "/tmp/charchannel2.socket" } }, "server" : true, "wait" : false }}}} <- {"return": {}}
Remove a character device backend
1.4
Send a break to a character device
2.10
Emitted when the guest opens or closes a virtio-serial port.
NOTE:
2.1
<- { "event": "VSERPORT_CHANGE", "data": { "id": "channel0", "open": true }, "timestamp": { "seconds": 1401385907, "microseconds": 422329 } }
An enumeration of guest-memory-dump's format.
2.0
Dump guest's memory to vmcore. It is a synchronous operation that can take very long depending on the amount of guest memory.
IMPORTANT: this option can make QEMU allocate several gigabytes of RAM. This can happen for a large guest, or a malicious guest pretending to be large.
Also, paging=true has the following limitations:
NOTE:
1.2
-> { "execute": "dump-guest-memory", "arguments": { "paging": false, "protocol": "fd:dump" } } <- { "return": {} }
Describe the status of a long-running background guest memory dump.
2.6
The result format for 'query-dump'.
2.6
Query latest dump status.
A DumpStatus object showing the dump status.
2.6
-> { "execute": "query-dump" } <- { "return": { "status": "active", "completed": 1024000, "total": 2048000 } }
Emitted when background dump has completed
2.6
<- { "event": "DUMP_COMPLETED", "data": { "result": { "total": 1090650112, "status": "completed", "completed": 1090650112 } }, "timestamp": { "seconds": 1648244171, "microseconds": 950316 } }
2.0
Returns the available formats for dump-guest-memory
A DumpGuestMemoryCapability object listing available formats for dump-guest-memory
2.0
-> { "execute": "query-dump-guest-memory-capability" } <- { "return": { "formats": ["elf", "kdump-zlib", "kdump-lzo", "kdump-snappy"] } }
Sets the link status of a virtual network adapter.
0.14
NOTE:
-> { "execute": "set_link", "arguments": { "name": "e1000.0", "up": false } } <- { "return": {} }
Add a network backend.
Additional arguments depend on the type.
0.14
-> { "execute": "netdev_add", "arguments": { "type": "user", "id": "netdev1", "dnssearch": [ { "str": "example.org" } ] } } <- { "return": {} }
Remove a network backend.
0.14
Create a new Network Interface Card.
1.2
A fat type wrapping 'str', to be embedded in lists.
1.2
Use the user mode network stack which requires no administrator privilege to run.
1.2
Used to configure a host TAP network interface backend.
1.2
Socket netdevs are used to establish a network connection to another QEMU virtual machine via a TCP socket.
1.2
Configure an Ethernet over L2TPv3 tunnel.
2.1
Connect to a vde switch running on the host.
1.2
Connect a host TAP network interface to a host bridge device.
1.2
Connect two or more net clients through a software hub.
1.2
Connect a client to a netmap-enabled NIC or to a VALE switch port
2.0
Attach mode for a default XDP program
8.2
CONFIG_AF_XDP
AF_XDP network backend
8.2
CONFIG_AF_XDP
Vhost-user network backend
2.1
Vhost-vdpa network backend
vDPA device is a device that uses a datapath which complies with the virtio specifications with a vendor specific control path.
5.1
vmnet (host mode) network backend.
Allows the vmnet interface to communicate with other vmnet interfaces that are in host mode and also with the host.
7.1
CONFIG_VMNET
vmnet (shared mode) network backend.
Allows traffic originating from the vmnet interface to reach the Internet through a network address translator (NAT). The vmnet interface can communicate with the host and with other shared mode interfaces on the same subnet. If no DHCP settings, subnet mask and IPv6 prefix specified, the interface can communicate with any of other interfaces in shared mode.
7.1
CONFIG_VMNET
vmnet (bridged mode) network backend.
Bridges the vmnet interface with a physical network interface.
7.1
CONFIG_VMNET
Configuration info for stream socket netdev
Only SocketAddress types 'unix', 'inet' and 'fd' are supported.
7.2
Configuration info for datagram socket netdev.
Only SocketAddress types 'unix', 'inet' and 'fd' are supported.
If remote address is present and it's a multicast address, local address is optional. Otherwise local address is required and remote address is optional.
remote | local | okay? |
absent | absent | no |
absent | not fd | no |
absent | fd | yes |
multicast | absent | yes |
multicast | present | yes |
not multicast | absent | no |
not multicast | present | yes |
7.2
Available netdev drivers.
2.7
Captures the configuration of a network device.
1.2
Packets receiving state
1.6
Rx-filter information for a NIC.
1.6
Return rx-filter information for all NICs (or for the given NIC).
list of RxFilterInfo for all NICs (or for the given NIC).
1.6
-> { "execute": "query-rx-filter", "arguments": { "name": "vnet0" } } <- { "return": [ { "promiscuous": true, "name": "vnet0", "main-mac": "52:54:00:12:34:56", "unicast": "normal", "vlan": "normal", "vlan-table": [ 4, 0 ], "unicast-table": [ ], "multicast": "normal", "multicast-overflow": false, "unicast-overflow": false, "multicast-table": [ "01:00:5e:00:00:01", "33:33:00:00:00:01", "33:33:ff:12:34:56" ], "broadcast-allowed": false } ] }
Emitted once until the 'query-rx-filter' command is executed, the first event will always be emitted
1.6
<- { "event": "NIC_RX_FILTER_CHANGED", "data": { "name": "vnet0", "path": "/machine/peripheral/vnet0/virtio-backend" }, "timestamp": { "seconds": 1368697518, "microseconds": 326866 } }
Parameters for self-announce timers
4.0
Trigger generation of broadcast RARP frames to update network switches. This can be useful when network bonds fail-over the active slave.
-> { "execute": "announce-self", "arguments": { "initial": 50, "max": 550, "rounds": 10, "step": 50, "interfaces": ["vn2", "vn3"], "id": "bob" } } <- { "return": {} }
4.0
Emitted when VIRTIO_NET_F_STANDBY was enabled during feature negotiation. Failover primary devices which were hidden (not hotplugged when requested) before will now be hotplugged by the virtio-net standby device.
4.2
<- { "event": "FAILOVER_NEGOTIATED", "data": { "device-id": "net1" }, "timestamp": { "seconds": 1368697518, "microseconds": 326866 } }
Emitted when the netdev stream backend is connected
7.2
<- { "event": "NETDEV_STREAM_CONNECTED", "data": { "netdev-id": "netdev0", "addr": { "port": "47666", "ipv6": true, "host": "::1", "type": "inet" } }, "timestamp": { "seconds": 1666269863, "microseconds": 311222 } }
<- { "event": "NETDEV_STREAM_CONNECTED", "data": { "netdev-id": "netdev0", "addr": { "path": "/tmp/qemu0", "type": "unix" } }, "timestamp": { "seconds": 1666269706, "microseconds": 413651 } }
Emitted when the netdev stream backend is disconnected
7.2
<- { "event": "NETDEV_STREAM_DISCONNECTED", "data": {"netdev-id": "netdev0"}, "timestamp": {"seconds": 1663330937, "microseconds": 526695} }
eBPF object is an ELF binary that contains the eBPF program and eBPF map description(BTF). Overall, eBPF object should contain the program and enough metadata to create/load eBPF with libbpf. As the eBPF maps/program should correspond to QEMU, the eBPF can't be used from different QEMU build.
Currently, there is a possible eBPF for receive-side scaling (RSS).
An eBPF ELF object.
9.0
CONFIG_EBPF
The eBPF programs that can be gotten with request-ebpf.
9.0
CONFIG_EBPF
Retrieve an eBPF object that can be loaded with libbpf. Management applications (e.g. libvirt) may load it and pass file descriptors to QEMU, so they can run running QEMU without BPF capabilities.
eBPF object encoded in base64.
9.0
CONFIG_EBPF
Rocker switch information.
2.4
Return rocker switch information.
Rocker information
2.4
-> { "execute": "query-rocker", "arguments": { "name": "sw1" } } <- { "return": {"name": "sw1", "ports": 2, "id": 1327446905938}}
An enumeration of port duplex states.
2.4
An enumeration of port autoneg states.
2.4
Rocker switch port information.
2.4
Return rocker switch port information.
a list of RockerPort information
2.4
-> { "execute": "query-rocker-ports", "arguments": { "name": "sw1" } } <- { "return": [ {"duplex": "full", "enabled": true, "name": "sw1.1", "autoneg": "off", "link-up": true, "speed": 10000}, {"duplex": "full", "enabled": true, "name": "sw1.2", "autoneg": "off", "link-up": true, "speed": 10000} ]}
Rocker switch OF-DPA flow key
NOTE:
2.4
Rocker switch OF-DPA flow mask
NOTE:
2.4
Rocker switch OF-DPA flow action
NOTE:
2.4
Rocker switch OF-DPA flow
2.4
Return rocker OF-DPA flow information.
rocker OF-DPA flow information
2.4
-> { "execute": "query-rocker-of-dpa-flows", "arguments": { "name": "sw1" } } <- { "return": [ {"key": {"in-pport": 0, "priority": 1, "tbl-id": 0}, "hits": 138, "cookie": 0, "action": {"goto-tbl": 10}, "mask": {"in-pport": 4294901760} }, {...}, ]}
Rocker switch OF-DPA group
NOTE:
2.4
Return rocker OF-DPA group information.
rocker OF-DPA group information
2.4
-> { "execute": "query-rocker-of-dpa-groups", "arguments": { "name": "sw1" } } <- { "return": [ {"type": 0, "out-pport": 2, "pport": 2, "vlan-id": 3841, "pop-vlan": 1, "id": 251723778}, {"type": 0, "out-pport": 0, "pport": 0, "vlan-id": 3841, "pop-vlan": 1, "id": 251723776}, {"type": 0, "out-pport": 1, "pport": 1, "vlan-id": 3840, "pop-vlan": 1, "id": 251658241}, {"type": 0, "out-pport": 0, "pport": 0, "vlan-id": 3840, "pop-vlan": 1, "id": 251658240} ]}
An enumeration of TPM models
1.5
CONFIG_TPM
Return a list of supported TPM models
a list of TpmModel
1.5
-> { "execute": "query-tpm-models" } <- { "return": [ "tpm-tis", "tpm-crb", "tpm-spapr" ] }
CONFIG_TPM
An enumeration of TPM types
1.5
CONFIG_TPM
Return a list of supported TPM types
a list of TpmType
1.5
CONFIG_TPM
Information about the TPM passthrough type
1.5
CONFIG_TPM
Information about the TPM emulator type
2.11
CONFIG_TPM
1.5
CONFIG_TPM
2.11
CONFIG_TPM
A union referencing different TPM backend types' configuration options
1.5
CONFIG_TPM
Information about the TPM
1.5
CONFIG_TPM
Return information about the TPM device
1.5
-> { "execute": "query-tpm" } <- { "return": [ { "model": "tpm-tis", "options": { "type": "passthrough", "data": { "cancel-path": "/sys/class/misc/tpm0/device/cancel", "path": "/dev/tpm0" } }, "id": "tpm0" } ] }
CONFIG_TPM
Display protocols which support changing password options.
7.0
An action to take on changing a password on a connection with active clients.
7.0
Options for set_password.
7.0
Options for set_password specific to the VNC protocol.
7.0
Set the password of a remote display server.
0.14
-> { "execute": "set_password", "arguments": { "protocol": "vnc", "password": "secret" } } <- { "return": {} }
General options for expire_password.
NOTE:
7.0
Options for expire_password specific to the VNC protocol.
7.0
Expire the password of a remote display server.
0.14
-> { "execute": "expire_password", "arguments": { "protocol": "vnc", "time": "+60" } } <- { "return": {} }
Supported image format types.
7.1
Capture the contents of a screen and write it to a file.
0.14
-> { "execute": "screendump", "arguments": { "filename": "/tmp/image" } } <- { "return": {} }
CONFIG_PIXMAN
The basic information for SPICE network connection
2.1
CONFIG_SPICE
Information about a SPICE server
2.1
CONFIG_SPICE
Information about a SPICE client channel.
0.14
CONFIG_SPICE
An enumeration of Spice mouse states.
1.1
CONFIG_SPICE
Information about the SPICE session.
0.14
CONFIG_SPICE
Returns information about the current SPICE server
SpiceInfo
0.14
-> { "execute": "query-spice" } <- { "return": { "enabled": true, "auth": "spice", "port": 5920, "migrated":false, "tls-port": 5921, "host": "0.0.0.0", "mouse-mode":"client", "channels": [ { "port": "54924", "family": "ipv4", "channel-type": 1, "connection-id": 1804289383, "host": "127.0.0.1", "channel-id": 0, "tls": true }, { "port": "36710", "family": "ipv4", "channel-type": 4, "connection-id": 1804289383, "host": "127.0.0.1", "channel-id": 0, "tls": false }, ... ] } }
CONFIG_SPICE
Emitted when a SPICE client establishes a connection
0.14
<- { "timestamp": {"seconds": 1290688046, "microseconds": 388707}, "event": "SPICE_CONNECTED", "data": { "server": { "port": "5920", "family": "ipv4", "host": "127.0.0.1"}, "client": {"port": "52873", "family": "ipv4", "host": "127.0.0.1"} }}
CONFIG_SPICE
Emitted after initial handshake and authentication takes place (if any) and the SPICE channel is up and running
0.14
<- { "timestamp": {"seconds": 1290688046, "microseconds": 417172}, "event": "SPICE_INITIALIZED", "data": {"server": {"auth": "spice", "port": "5921", "family": "ipv4", "host": "127.0.0.1"}, "client": {"port": "49004", "family": "ipv4", "channel-type": 3, "connection-id": 1804289383, "host": "127.0.0.1", "channel-id": 0, "tls": true} }}
CONFIG_SPICE
Emitted when the SPICE connection is closed
0.14
<- { "timestamp": {"seconds": 1290688046, "microseconds": 388707}, "event": "SPICE_DISCONNECTED", "data": { "server": { "port": "5920", "family": "ipv4", "host": "127.0.0.1"}, "client": {"port": "52873", "family": "ipv4", "host": "127.0.0.1"} }}
CONFIG_SPICE
Emitted when SPICE migration has completed
1.3
<- { "timestamp": {"seconds": 1290688046, "microseconds": 417172}, "event": "SPICE_MIGRATE_COMPLETED" }
CONFIG_SPICE
The basic information for vnc network connection
2.1
CONFIG_VNC
The network connection information for server
2.1
CONFIG_VNC
Information about a connected VNC client.
0.14
CONFIG_VNC
Information about the VNC session.
0.14
CONFIG_VNC
vnc primary authentication method.
2.3
CONFIG_VNC
vnc sub authentication method with vencrypt.
2.3
CONFIG_VNC
The network connection information for server
2.9
CONFIG_VNC
Information about a vnc server
2.3
CONFIG_VNC
Returns information about the current VNC server
VncInfo
0.14
-> { "execute": "query-vnc" } <- { "return": { "enabled":true, "host":"0.0.0.0", "service":"50402", "auth":"vnc", "family":"ipv4", "clients":[ { "host":"127.0.0.1", "service":"50401", "family":"ipv4", "websocket":false } ] } }
CONFIG_VNC
Returns a list of vnc servers. The list can be empty.
a list of VncInfo2
2.3
CONFIG_VNC
Change the VNC server password.
1.1
NOTE:
CONFIG_VNC
Emitted when a VNC client establishes a connection
NOTE:
0.13
<- { "event": "VNC_CONNECTED", "data": { "server": { "auth": "sasl", "family": "ipv4", "websocket": false, "service": "5901", "host": "0.0.0.0" }, "client": { "family": "ipv4", "service": "58425", "host": "127.0.0.1", "websocket": false } }, "timestamp": { "seconds": 1262976601, "microseconds": 975795 } }
CONFIG_VNC
Emitted after authentication takes place (if any) and the VNC session is made active
0.13
<- { "event": "VNC_INITIALIZED", "data": { "server": { "auth": "sasl", "family": "ipv4", "websocket": false, "service": "5901", "host": "0.0.0.0"}, "client": { "family": "ipv4", "service": "46089", "websocket": false, "host": "127.0.0.1", "sasl_username": "luiz" } }, "timestamp": { "seconds": 1263475302, "microseconds": 150772 } }
CONFIG_VNC
Emitted when the connection is closed
0.13
<- { "event": "VNC_DISCONNECTED", "data": { "server": { "auth": "sasl", "family": "ipv4", "websocket": false, "service": "5901", "host": "0.0.0.0" }, "client": { "family": "ipv4", "service": "58425", "websocket": false, "host": "127.0.0.1", "sasl_username": "luiz" } }, "timestamp": { "seconds": 1262976601, "microseconds": 975795 } }
CONFIG_VNC
Information about a mouse device.
0.14
Returns information about each active mouse device
a list of MouseInfo for each device
0.14
-> { "execute": "query-mice" } <- { "return": [ { "name":"QEMU Microsoft Mouse", "index":0, "current":false, "absolute":false }, { "name":"QEMU PS/2 Mouse", "index":1, "current":true, "absolute":true } ] }
An enumeration of key name.
This is used by the send-key command.
'sysrq' was mistakenly added to hack around the fact that the ps2 driver was not generating correct scancodes sequences when 'alt+print' was pressed. This flaw is now fixed and the 'sysrq' key serves no further purpose. Any further use of 'sysrq' will be transparently changed to 'print', so they are effectively synonyms.
1.3
1.3
1.3
1.3
Represents a keyboard key.
1.3
Send keys to guest.
1.3
-> { "execute": "send-key", "arguments": { "keys": [ { "type": "qcode", "data": "ctrl" }, { "type": "qcode", "data": "alt" }, { "type": "qcode", "data": "delete" } ] } } <- { "return": {} }
Button of a pointer input device (mouse, tablet).
2.0
Position axis of a pointer input device (mouse, tablet).
2.0
Type of a multi-touch event.
8.1
Keyboard input event.
2.0
Pointer button input event.
2.0
Pointer motion input event.
2.0
MultiTouch input event.
8.1
2.0
2.0
2.0
2.0
8.1
Input event union.
2.0
Send input event(s) to guest.
The device and head parameters can be used to send the input event to specific input devices in case (a) multiple input devices of the same kind are added to the virtual machine and (b) you have configured input routing (see docs/multiseat.txt) for those input devices. The parameters work exactly like the device and head properties of input devices. If device is missing, only devices that have no input routing config are admissible. If device is specified, both input devices with and without input routing config are admissible, but devices with input routing config take precedence.
2.6
NOTE:
-> { "execute": "input-send-event", "arguments": { "device": "video0", "events": [ { "type": "btn", "data" : { "down": true, "button": "left" } } ] } } <- { "return": {} } -> { "execute": "input-send-event", "arguments": { "device": "video0", "events": [ { "type": "btn", "data" : { "down": false, "button": "left" } } ] } } <- { "return": {} }
-> { "execute": "input-send-event", "arguments": { "events": [ { "type": "key", "data" : { "down": true, "key": {"type": "qcode", "data": "ctrl" } } }, { "type": "key", "data" : { "down": true, "key": {"type": "qcode", "data": "alt" } } }, { "type": "key", "data" : { "down": true, "key": {"type": "qcode", "data": "delete" } } } ] } } <- { "return": {} }
-> { "execute": "input-send-event" , "arguments": { "events": [ { "type": "abs", "data" : { "axis": "x", "value" : 20000 } }, { "type": "abs", "data" : { "axis": "y", "value" : 400 } } ] } } <- { "return": {} }
GTK display options.
2.12
EGL headless display options.
3.1
DBus display options.
7.0
Display OpenGL mode.
3.0
Curses display options.
4.0
Cocoa display options.
7.0
Set of modifier keys that need to be held for shortcut key actions.
7.1
SDL2 display options.
7.1
Display (user interface) type.
2.12
Display (user interface) options.
2.12
Returns information about display configuration
DisplayOptions
3.1
Available DisplayReload types.
6.0
Specify the VNC reload options.
6.0
Options of the display configuration reload.
6.0
Reload display configuration.
6.0
-> { "execute": "display-reload", "arguments": { "type": "vnc", "tls-certs": true } } <- { "return": {} }
Available DisplayUpdate types.
7.1
Specify the VNC reload options.
7.1
Options of the display configuration reload.
7.1
Update display configuration.
7.1
-> { "execute": "display-update", "arguments": { "type": "vnc", "addresses": [ { "type": "inet", "host": "0.0.0.0", "port": "5901" } ] } } <- { "return": {} }
Set migration information for remote display. This makes the server ask the client to automatically reconnect using the new parameters once migration finished successfully. Only implemented for SPICE.
0.14
-> { "execute": "client_migrate_info", "arguments": { "protocol": "spice", "hostname": "virt42.lab.kraxel.org", "port": 1234 } } <- { "return": {} }
The authorization policy result
4.0
The authorization policy match format
4.0
A single authorization rule.
4.0
Properties for authz-list objects.
4.0
Properties for authz-listfile objects.
4.0
Properties for authz-pam objects.
4.0
Properties for authz-simple objects.
4.0
Detailed migration status.
0.14
Detailed XBZRLE migration cache statistics
1.2
Detailed migration compression statistics
3.1
An enumeration of migration status.
2.3
Detailed VFIO devices migration statistics
5.2
Information about current migration process.
0.14
Returns information about current migration process. If migration is active there will be another json-object with RAM migration status.
MigrationInfo
0.14
-> { "execute": "query-migrate" } <- { "return": {} }
-> { "execute": "query-migrate" } <- { "return": { "status": "completed", "total-time":12345, "setup-time":12345, "downtime":12345, "ram":{ "transferred":123, "remaining":123, "total":246, "duplicate":123, "normal":123, "normal-bytes":123456, "dirty-sync-count":15 } } }
-> { "execute": "query-migrate" } <- { "return": { "status": "failed" } }
-> { "execute": "query-migrate" } <- { "return":{ "status":"active", "total-time":12345, "setup-time":12345, "expected-downtime":12345, "ram":{ "transferred":123, "remaining":123, "total":246, "duplicate":123, "normal":123, "normal-bytes":123456, "dirty-sync-count":15 } } }
-> { "execute": "query-migrate" } <- { "return":{ "status":"active", "total-time":12345, "setup-time":12345, "expected-downtime":12345, "ram":{ "total":1057024, "remaining":1053304, "transferred":3720, "duplicate":10, "normal":3333, "normal-bytes":3412992, "dirty-sync-count":15 }, "xbzrle-cache":{ "cache-size":67108864, "bytes":20971520, "pages":2444343, "cache-miss":2244, "cache-miss-rate":0.123, "encoding-rate":80.1, "overflow":34434 } } }
Migration capabilities enumeration
1.2
Migration capability information
1.2
Enable/Disable the following migration capabilities (like xbzrle)
1.2
-> { "execute": "migrate-set-capabilities" , "arguments": { "capabilities": [ { "capability": "xbzrle", "state": true } ] } } <- { "return": {} }
Returns information about the current migration capabilities status
MigrationCapabilityStatus
1.2
-> { "execute": "query-migrate-capabilities" } <- { "return": [ {"state": false, "capability": "xbzrle"}, {"state": false, "capability": "rdma-pin-all"}, {"state": false, "capability": "auto-converge"}, {"state": false, "capability": "zero-blocks"}, {"state": true, "capability": "events"}, {"state": false, "capability": "postcopy-ram"}, {"state": false, "capability": "x-colo"} ]}
An enumeration of multifd compression methods.
5.0
This mode allows the user to quit QEMU, optionally update and reboot the OS, and restart QEMU. If the user reboots, the URI must persist across the reboot, such as by using a file.
Unlike normal mode, the use of certain local storage options does not block the migration, but the user must not modify the contents of guest block devices between the quit and restart.
This mode supports VFIO devices provided the user first puts the guest in the suspended runstate, such as by issuing guest-suspend-ram to the QEMU guest agent.
Best performance is achieved when the memory backend is shared and the x-ignore-shared migration capability is set, but this is not required. Further, if the user reboots before restarting such a configuration, the shared memory must persist across the reboot, such as by backing it with a dax device.
cpr-reboot may not be used with postcopy, background-snapshot, or COLO.
(since 8.2)
9.0
6.0
5.2
Maps a block node name and the bitmaps it has to aliases for dirty bitmap migration.
5.2
Migration parameters enumeration
Note: empty value works only since 2.9.
2.4
Note: empty value works only since 2.9.
2.4
Set various migration parameters.
2.4
-> { "execute": "migrate-set-parameters" , "arguments": { "multifd-channels": 5 } } <- { "return": {} }
The optional members aren't actually optional.
Note: 2.8 omits empty tls-creds instead.
Note: 2.8 omits empty tls-hostname instead.
2.4
Returns information about the current migration parameters
MigrationParameters
2.4
-> { "execute": "query-migrate-parameters" } <- { "return": { "multifd-channels": 2, "cpu-throttle-increment": 10, "cpu-throttle-initial": 20, "max-bandwidth": 33554432, "downtime-limit": 300 } }
Followup to a migration command to switch the migration to postcopy mode. The postcopy-ram capability must be set on both source and destination before the original migration command.
2.5
Emitted when a migration event happens
2.4
<- {"timestamp": {"seconds": 1432121972, "microseconds": 744001}, "event": "MIGRATION", "data": {"status": "completed"} }
Emitted from the source side of a migration at the start of each pass (when it syncs the dirty bitmap)
2.6
<- { "timestamp": {"seconds": 1449669631, "microseconds": 239225}, "event": "MIGRATION_PASS", "data": {"pass": 2} }
The message transmission between Primary side and Secondary side.
2.8
The COLO current mode.
2.8
An enumeration of COLO failover status
2.8
Emitted when VM finishes COLO mode due to some errors happening or at the request of users.
3.1
<- { "timestamp": {"seconds": 2032141960, "microseconds": 417172}, "event": "COLO_EXIT", "data": {"mode": "primary", "reason": "request" } }
The reason for a COLO exit.
3.1
Tell qemu that heartbeat is lost, request it to do takeover procedures. If this command is sent to the PVM, the Primary side will exit COLO mode. If sent to the Secondary, the Secondary side will run failover work, then takes over server operation to become the service VM.
2.8
CONFIG_REPLICATION
Cancel the current executing migration process.
NOTE:
0.14
Continue migration when it's in a paused state.
2.11
-> { "execute": "migrate-continue" , "arguments": { "state": "pre-switchover" } } <- { "return": {} }
The migration stream transport mechanisms.
8.2
8.2
8.2
Migration endpoint configuration.
8.2
The migration channel-type request options.
8.1
Migration stream channel parameters.
8.1
Migrates the current running guest to another Virtual Machine.
0.14
-> { "execute": "migrate", "arguments": { "uri": "tcp:0:4446" } } <- { "return": {} } -> { "execute": "migrate", "arguments": { "channels": [ { "channel-type": "main", "addr": { "transport": "socket", "type": "inet", "host": "10.12.34.9", "port": "1050" } } ] } } <- { "return": {} } -> { "execute": "migrate", "arguments": { "channels": [ { "channel-type": "main", "addr": { "transport": "exec", "args": [ "/bin/nc", "-p", "6000", "/some/sock" ] } } ] } } <- { "return": {} } -> { "execute": "migrate", "arguments": { "channels": [ { "channel-type": "main", "addr": { "transport": "rdma", "host": "10.12.34.9", "port": "1050" } } ] } } <- { "return": {} } -> { "execute": "migrate", "arguments": { "channels": [ { "channel-type": "main", "addr": { "transport": "file", "filename": "/tmp/migfile", "offset": "0x1000" } } ] } } <- { "return": {} }
Start an incoming migration, the qemu must have been started with -incoming defer
2.3
-> { "execute": "migrate-incoming", "arguments": { "uri": "tcp:0:4446" } } <- { "return": {} } -> { "execute": "migrate-incoming", "arguments": { "channels": [ { "channel-type": "main", "addr": { "transport": "socket", "type": "inet", "host": "10.12.34.9", "port": "1050" } } ] } } <- { "return": {} } -> { "execute": "migrate-incoming", "arguments": { "channels": [ { "channel-type": "main", "addr": { "transport": "exec", "args": [ "/bin/nc", "-p", "6000", "/some/sock" ] } } ] } } <- { "return": {} } -> { "execute": "migrate-incoming", "arguments": { "channels": [ { "channel-type": "main", "addr": { "transport": "rdma", "host": "10.12.34.9", "port": "1050" } } ] } } <- { "return": {} }
Save the state of all devices to file. The RAM and the block devices of the VM are not saved by this command.
1.1
-> { "execute": "xen-save-devices-state", "arguments": { "filename": "/tmp/save" } } <- { "return": {} }
Enable or disable the global dirty log mode.
1.3
-> { "execute": "xen-set-global-dirty-log", "arguments": { "enable": true } } <- { "return": {} }
Load the state of all devices from file. The RAM and the block devices of the VM are not loaded by this command.
2.7
-> { "execute": "xen-load-devices-state", "arguments": { "filename": "/tmp/resume" } } <- { "return": {} }
Enable or disable replication.
-> { "execute": "xen-set-replication", "arguments": {"enable": true, "primary": false} } <- { "return": {} }
2.9
CONFIG_REPLICATION
The result format for 'query-xen-replication-status'.
2.9
CONFIG_REPLICATION
Query replication status while the vm is running.
A ReplicationStatus object showing the status.
2.9
CONFIG_REPLICATION
Xen uses this command to notify replication to trigger a checkpoint.
2.9
CONFIG_REPLICATION
The result format for 'query-colo-status'.
3.1
CONFIG_REPLICATION
Query COLO status while the vm is running.
A COLOStatus object showing the status.
-> { "execute": "query-colo-status" } <- { "return": { "mode": "primary", "last-mode": "none", "reason": "request" } }
3.1
CONFIG_REPLICATION
Provide a recovery migration stream URI.
-> { "execute": "migrate-recover", "arguments": { "uri": "tcp:192.168.1.200:12345" } } <- { "return": {} }
3.0
Pause a migration. Currently it only supports postcopy.
3.0
Emitted from source side of a migration when migration state is WAIT_UNPLUG. Device was unplugged by guest operating system. Device resources in QEMU are kept on standby to be able to re-plug it in case of migration failure.
4.2
<- { "event": "UNPLUG_PRIMARY", "data": { "device-id": "hostdev0" }, "timestamp": { "seconds": 1265044230, "microseconds": 450486 } }
Dirty rate of vcpu.
6.2
Dirty page rate measurement status.
5.2
Method used to measure dirty page rate. Differences between available methods are explained in calc-dirty-rate.
6.2
Specifies unit in which time-related value is specified.
8.2
Information about measured dirty page rate.
5.2
Start measuring dirty page rate of the VM. Results can be retrieved with query-dirty-rate after measurements are completed.
Dirty page rate is the number of pages changed in a given time period expressed in MiB/s. The following methods of calculation are available:
5.2
-> {"execute": "calc-dirty-rate", "arguments": {"calc-time": 1, "sample-pages": 512} } <- { "return": {} }
Measure dirty rate using dirty bitmap for 500 milliseconds:
-> {"execute": "calc-dirty-rate", "arguments": {"calc-time": 500, "calc-time-unit": "millisecond", "mode": "dirty-bitmap"} } <- { "return": {} }
Query results of the most recent invocation of calc-dirty-rate.
5.2
<- {"status": "measuring", "sample-pages": 512, "mode": "page-sampling", "start-time": 1693900454, "calc-time": 10, "calc-time-unit": "second"}
<- {"status": "measured", "sample-pages": 512, "dirty-rate": 108, "mode": "page-sampling", "start-time": 1693900454, "calc-time": 10, "calc-time-unit": "second"}
Dirty page rate limit information of a virtual CPU.
7.1
Set the upper limit of dirty page rate for virtual CPUs.
Requires KVM with accelerator property "dirty-ring-size" set. A virtual CPU's dirty page rate is a measure of its memory load. To observe dirty page rates, use calc-dirty-rate.
7.1
-> {"execute": "set-vcpu-dirty-limit"} "arguments": { "dirty-rate": 200, "cpu-index": 1 } } <- { "return": {} }
Cancel the upper limit of dirty page rate for virtual CPUs.
Cancel the dirty page limit for the vCPU which has been set with set-vcpu-dirty-limit command. Note that this command requires support from dirty ring, same as the "set-vcpu-dirty-limit".
7.1
-> {"execute": "cancel-vcpu-dirty-limit"}, "arguments": { "cpu-index": 1 } } <- { "return": {} }
Returns information about virtual CPU dirty page rate limits, if any.
7.1
-> {"execute": "query-vcpu-dirty-limit"} <- {"return": [ { "limit-rate": 60, "current-rate": 3, "cpu-index": 0}, { "limit-rate": 60, "current-rate": 3, "cpu-index": 1}]}
Information about migrationthreads
7.2
Returns information of migration threads
MigrationThreadInfo
7.2
Save a VM snapshot
Applications should not assume that the snapshot save is complete when this command returns. The job commands / events must be used to determine completion and to fetch details of any errors that arise.
Note that execution of the guest CPUs may be stopped during the time it takes to save the snapshot. A future version of QEMU may ensure CPUs are executing continuously.
It is strongly recommended that devices contain all writable block device nodes if a consistent snapshot is required.
If tag already exists, an error will be reported
-> { "execute": "snapshot-save", "arguments": { "job-id": "snapsave0", "tag": "my-snap", "vmstate": "disk0", "devices": ["disk0", "disk1"] } } <- { "return": { } } <- {"event": "JOB_STATUS_CHANGE", "timestamp": {"seconds": 1432121972, "microseconds": 744001}, "data": {"status": "created", "id": "snapsave0"}} <- {"event": "JOB_STATUS_CHANGE", "timestamp": {"seconds": 1432122172, "microseconds": 744001}, "data": {"status": "running", "id": "snapsave0"}} <- {"event": "STOP", "timestamp": {"seconds": 1432122372, "microseconds": 744001} } <- {"event": "RESUME", "timestamp": {"seconds": 1432122572, "microseconds": 744001} } <- {"event": "JOB_STATUS_CHANGE", "timestamp": {"seconds": 1432122772, "microseconds": 744001}, "data": {"status": "waiting", "id": "snapsave0"}} <- {"event": "JOB_STATUS_CHANGE", "timestamp": {"seconds": 1432122972, "microseconds": 744001}, "data": {"status": "pending", "id": "snapsave0"}} <- {"event": "JOB_STATUS_CHANGE", "timestamp": {"seconds": 1432123172, "microseconds": 744001}, "data": {"status": "concluded", "id": "snapsave0"}} -> {"execute": "query-jobs"} <- {"return": [{"current-progress": 1, "status": "concluded", "total-progress": 1, "type": "snapshot-save", "id": "snapsave0"}]}
6.0
Load a VM snapshot
Applications should not assume that the snapshot load is complete when this command returns. The job commands / events must be used to determine completion and to fetch details of any errors that arise.
Note that execution of the guest CPUs will be stopped during the time it takes to load the snapshot.
It is strongly recommended that devices contain all writable block device nodes that can have changed since the original snapshot-save command execution.
-> { "execute": "snapshot-load", "arguments": { "job-id": "snapload0", "tag": "my-snap", "vmstate": "disk0", "devices": ["disk0", "disk1"] } } <- { "return": { } } <- {"event": "JOB_STATUS_CHANGE", "timestamp": {"seconds": 1472124172, "microseconds": 744001}, "data": {"status": "created", "id": "snapload0"}} <- {"event": "JOB_STATUS_CHANGE", "timestamp": {"seconds": 1472125172, "microseconds": 744001}, "data": {"status": "running", "id": "snapload0"}} <- {"event": "STOP", "timestamp": {"seconds": 1472125472, "microseconds": 744001} } <- {"event": "RESUME", "timestamp": {"seconds": 1472125872, "microseconds": 744001} } <- {"event": "JOB_STATUS_CHANGE", "timestamp": {"seconds": 1472126172, "microseconds": 744001}, "data": {"status": "waiting", "id": "snapload0"}} <- {"event": "JOB_STATUS_CHANGE", "timestamp": {"seconds": 1472127172, "microseconds": 744001}, "data": {"status": "pending", "id": "snapload0"}} <- {"event": "JOB_STATUS_CHANGE", "timestamp": {"seconds": 1472128172, "microseconds": 744001}, "data": {"status": "concluded", "id": "snapload0"}} -> {"execute": "query-jobs"} <- {"return": [{"current-progress": 1, "status": "concluded", "total-progress": 1, "type": "snapshot-load", "id": "snapload0"}]}
6.0
Delete a VM snapshot
Applications should not assume that the snapshot delete is complete when this command returns. The job commands / events must be used to determine completion and to fetch details of any errors that arise.
-> { "execute": "snapshot-delete", "arguments": { "job-id": "snapdelete0", "tag": "my-snap", "devices": ["disk0", "disk1"] } } <- { "return": { } } <- {"event": "JOB_STATUS_CHANGE", "timestamp": {"seconds": 1442124172, "microseconds": 744001}, "data": {"status": "created", "id": "snapdelete0"}} <- {"event": "JOB_STATUS_CHANGE", "timestamp": {"seconds": 1442125172, "microseconds": 744001}, "data": {"status": "running", "id": "snapdelete0"}} <- {"event": "JOB_STATUS_CHANGE", "timestamp": {"seconds": 1442126172, "microseconds": 744001}, "data": {"status": "waiting", "id": "snapdelete0"}} <- {"event": "JOB_STATUS_CHANGE", "timestamp": {"seconds": 1442127172, "microseconds": 744001}, "data": {"status": "pending", "id": "snapdelete0"}} <- {"event": "JOB_STATUS_CHANGE", "timestamp": {"seconds": 1442128172, "microseconds": 744001}, "data": {"status": "concluded", "id": "snapdelete0"}} -> {"execute": "query-jobs"} <- {"return": [{"current-progress": 1, "status": "concluded", "total-progress": 1, "type": "snapshot-delete", "id": "snapdelete0"}]}
6.0
This action can be used to test transaction failure.
1.6
An enumeration of Transactional completion modes.
2.5
1.1
1.6
2.5
2.5
4.0
2.3
2.5
1.7
1.1
1.6
A discriminated record of operations that can be performed with transaction.
1.1
Optional arguments to modify the behavior of a Transaction.
2.5
Executes a number of transactionable QMP commands atomically. If any operation fails, then the entire set of actions will be abandoned and the appropriate error returned.
For external snapshots, the dictionary contains the device, the file to use for the new snapshot, and the format. The default format, if not specified, is qcow2.
Each new snapshot defaults to being created by QEMU (wiping any contents if the file already exists), but it is also possible to reuse an externally-created file. In the latter case, you should ensure that the new image file has the same contents as the current one; QEMU cannot perform any meaningful check. Typically this is achieved by using the current image file as the backing file for the new image.
On failure, the original disks pre-snapshot attempt will be used.
For internal snapshots, the dictionary contains the device and the snapshot's name. If an internal snapshot matching name already exists, the request will be rejected. Only some image formats support it, for example, qcow2, and rbd,
On failure, qemu will try delete the newly created internal snapshot in the transaction. When an I/O error occurs during deletion, the user needs to fix it later with qemu-img or other command.
NOTE:
1.1
-> { "execute": "transaction", "arguments": { "actions": [ { "type": "blockdev-snapshot-sync", "data" : { "device": "ide-hd0", "snapshot-file": "/some/place/my-image", "format": "qcow2" } }, { "type": "blockdev-snapshot-sync", "data" : { "node-name": "myfile", "snapshot-file": "/some/place/my-image2", "snapshot-node-name": "node3432", "mode": "existing", "format": "qcow2" } }, { "type": "blockdev-snapshot-sync", "data" : { "device": "ide-hd1", "snapshot-file": "/some/place/my-image2", "mode": "existing", "format": "qcow2" } }, { "type": "blockdev-snapshot-internal-sync", "data" : { "device": "ide-hd2", "name": "snapshot0" } } ] } } <- { "return": {} }
State of a tracing event.
2.2
Information of a tracing event.
2.2
Query the state of events.
a list of TraceEventInfo for the matching events
2.2
-> { "execute": "trace-event-get-state", "arguments": { "name": "qemu_memalign" } } <- { "return": [ { "name": "qemu_memalign", "state": "disabled", "vcpu": false } ] }
Set the dynamic tracing state of events.
2.2
-> { "execute": "trace-event-set-state", "arguments": { "name": "qemu_memalign", "enable": true } } <- { "return": {} }
Policy for handling "funny" input.
6.0
Policy for handling "funny" output.
6.0
Policy for handling deprecated management interfaces.
This is intended for testing users of the management interfaces.
Limitation: covers only syntactic aspects of QMP, i.e. stuff tagged with feature 'deprecated' or 'unstable'. We may want to extend it to cover semantic aspects and CLI.
Limitation: deprecated-output policy hide is not implemented for enumeration values. They behave the same as with policy accept.
6.0
Enable QMP capabilities.
-> { "execute": "qmp_capabilities", "arguments": { "enable": [ "oob" ] } } <- { "return": {} }
NOTE:
NOTE:
0.13
Enumeration of capabilities to be advertised during initial client connection, used for agreeing on particular QMP extension behaviors.
2.12
A three-part version number.
2.4
A description of QEMU's version.
0.14
Returns the current version of QEMU.
A VersionInfo object describing the current version of QEMU.
0.14
-> { "execute": "query-version" } <- { "return":{ "qemu":{ "major":0, "minor":11, "micro":5 }, "package":"" } }
Information about a QMP command
0.14
Return a list of supported QMP commands by this server
A list of CommandInfo for all supported commands
0.14
-> { "execute": "query-commands" } <- { "return":[ { "name":"query-balloon" }, { "name":"system_powerdown" }, ... ] }
This example has been shortened as the real response is too long.
This command will cause the QEMU process to exit gracefully. While every attempt is made to send the QMP response before terminating, this is not guaranteed. When using this interface, a premature EOF would not be unexpected.
0.14
An enumeration of monitor modes.
5.0
Options to be used for adding a new monitor.
5.0
Command query-qmp-schema exposes the QMP wire ABI as an array of SchemaInfo. This lets QMP clients figure out what commands and events are available in this QEMU, and their parameters and results.
However, the SchemaInfo can't reflect all the rules and restrictions that apply to QMP. It's interface introspection (figuring out what's there), not interface specification. The specification is in the QAPI schema.
Furthermore, while we strive to keep the QMP wire format backwards-compatible across qemu versions, the introspection output is not guaranteed to have the same stability. For example, one version of qemu may list an object member as an optional non-variant, while another lists the same member only through the object's variants; or the type of a member may change from a generic string into a specific enum or from one specific type into an alternate that includes the original type alongside something else.
array of SchemaInfo, where each element describes an entity in the ABI: command, event, type, ...
The order of the various SchemaInfo is unspecified; however, all names are guaranteed to be unique (no name will be duplicated with different meta-types).
NOTE:
2.5
This is a SchemaInfo's meta type, i.e. the kind of entity it describes.
2.5
2.5
Additional SchemaInfo members for meta-type 'builtin'.
2.5
The four primitive and two structured types according to RFC 8259 section 1, plus 'int' (split off 'number'), plus the obvious top type 'value'.
2.5
Additional SchemaInfo members for meta-type 'enum'.
Values of this type are JSON string on the wire.
2.5
An object member.
6.2
Additional SchemaInfo members for meta-type 'array'.
Values of this type are JSON array on the wire.
2.5
Additional SchemaInfo members for meta-type 'object'.
Values of this type are JSON object on the wire.
2.5
An object member.
2.5
The variant members for a value of the type tag.
2.5
Additional SchemaInfo members for meta-type 'alternate'.
On the wire, this can be any of the members.
2.5
An alternate member.
2.5
Additional SchemaInfo members for meta-type 'command'.
2.5
Additional SchemaInfo members for meta-type 'event'.
2.5
1.2
This command will list any properties of a object given a path in the object model.
a list of ObjectPropertyInfo that describe the properties of the object.
1.2
-> { "execute": "qom-list", "arguments": { "path": "/chardevs" } } <- { "return": [ { "name": "type", "type": "string" }, { "name": "parallel0", "type": "child<chardev-vc>" }, { "name": "serial0", "type": "child<chardev-vc>" }, { "name": "mon0", "type": "child<chardev-stdio>" } ] }
This command will get a property from a object model path and return the value.
Absolute paths are derived from the root object and can follow child<> or link<> properties. Since they can follow link<> properties, they can be arbitrarily long. Absolute paths look like absolute filenames and are prefixed with a leading slash.
Partial paths look like relative filenames. They do not begin with a prefix. The matching rules for partial paths are subtle but designed to make specifying objects easy. At each level of the composition tree, the partial path is matched as an absolute path. The first match is not returned. At least two matches are searched for. A successful result is only returned if only one match is found. If more than one match is found, a flag is return to indicate that the match was ambiguous.
The property value. The type depends on the property type. child<> and link<> properties are returned as #str pathnames. All integer property types (u8, u16, etc) are returned as #int.
1.2
-> { "execute": "qom-get", "arguments": { "path": "/machine/unattached/device[0]", "property": "hotplugged" } } <- { "return": false }
-> { "execute": "qom-get", "arguments": { "path": "unattached/sysbus", "property": "type" } } <- { "return": "System" }
This command will set a property from a object model path.
1.2
-> { "execute": "qom-set", "arguments": { "path": "/machine", "property": "graphics", "value": false } } <- { "return": {} }
This structure describes a search result from qom-list-types
1.1
This command will return a list of types given search parameters
a list of ObjectTypeInfo or an empty list if no results are found
1.1
List properties associated with a QOM object.
NOTE:
a list of ObjectPropertyInfo describing object properties
2.12
Properties for can-host-socketcan objects.
2.12
CONFIG_LINUX
Properties for colo-compare objects.
2.8
Properties for cryptodev-backend and cryptodev-backend-builtin objects.
2.8
Properties for cryptodev-vhost-user objects.
2.12
CONFIG_VHOST_CRYPTO
Properties for dbus-vmstate objects.
5.0
Indicates where to insert a netfilter relative to a given other filter.
5.0
Properties for objects of classes derived from netfilter.
2.5
Properties for filter-buffer objects.
2.5
Properties for filter-dump objects.
2.5
Properties for filter-mirror objects.
2.6
Properties for filter-redirector objects.
At least one of indev or outdev must be present. If both are present, they must not refer to the same character device backend.
2.6
Properties for filter-rewriter objects.
2.8
Properties for input-barrier objects.
4.2
Properties for input-linux objects.
2.6
CONFIG_LINUX
Common properties for event loops
7.1
Properties for iothread objects.
The aio-max-batch option is available since 6.1.
2.0
Properties for the main-loop object.
7.1
Properties for objects of classes derived from memory-backend.
NOTE:
2.1
Properties for memory-backend-file objects.
2.1
Properties for memory-backend-memfd objects.
2.12
CONFIG_LINUX
Properties for memory-backend-shm objects.
This memory backend supports only shared memory, which is the default.
9.1
CONFIG_POSIX
Properties for memory-backend-epc objects.
The merge boolean option is false by default with epc
The dump boolean option is false by default with epc
6.2
CONFIG_LINUX
Properties for pr-manager-helper objects.
2.11
CONFIG_LINUX
Properties for qtest objects.
6.0
Properties for x-remote-object objects.
6.0
Properties for x-vfio-user-server objects.
7.1
Properties for iommufd objects.
9.0
Properties for acpi-generic-initiator objects.
9.0
Properties for acpi-generic-port objects.
9.2
Properties for objects of classes derived from rng.
1.3
Properties for rng-egd objects.
1.3
Properties for rng-random objects.
1.3
CONFIG_POSIX
Properties common to objects that are derivatives of sev-common.
9.1
Properties for sev-guest objects.
2.12
Properties for sev-snp-guest objects. Most of these are direct arguments for the KVM_SNP_* interfaces documented in the Linux kernel source under Documentation/arch/x86/amd-memory-encryption.rst, which are in turn closely coupled with the SNP_INIT/SNP_LAUNCH_* firmware commands documented in the SEV-SNP Firmware ABI Specification (Rev 0.9).
More usage information is also available in the QEMU source tree under docs/amd-memory-encryption.
9.1
Properties for thread context objects.
7.2
6.0
Describes the options of a user creatable QOM object.
6.0
Create a QOM object.
2.0
-> { "execute": "object-add", "arguments": { "qom-type": "rng-random", "id": "rng1", "filename": "/dev/hwrng" } } <- { "return": {} }
Remove a QOM object.
2.0
List properties associated with a device.
a list of ObjectPropertyInfo describing a devices properties
NOTE:
1.2
Add a device.
-> { "execute": "device_add", "arguments": { "driver": "e1000", "id": "net1", "bus": "pci.0", "mac": "52:54:00:12:34:56" } } <- { "return": {} }
0.13
Remove a device from a guest
NOTE:
0.14
-> { "execute": "device_del", "arguments": { "id": "/machine/peripheral-anon/device[0]" } } <- { "return": {} }
Emitted whenever the device removal completion is acknowledged by the guest. At this point, it's safe to reuse the specified device ID. Device removal can be initiated by the guest or by HMP/QMP commands.
1.5
<- { "event": "DEVICE_DELETED", "data": { "device": "virtio-net-pci-0", "path": "/machine/peripheral/virtio-net-pci-0" }, "timestamp": { "seconds": 1265044230, "microseconds": 450486 } }
Emitted when a device hot unplug fails due to a guest reported error.
6.2
<- { "event": "DEVICE_UNPLUG_GUEST_ERROR", "data": { "device": "core1", "path": "/machine/peripheral/core1" }, "timestamp": { "seconds": 1615570772, "microseconds": 202844 } }
Synchronize device configuration from host to guest part. First, copy the configuration from the host part (backend) to the guest part (frontend). Then notify guest software that device configuration changed.
The command may be used to notify the guest about block device capcity change. Currently only vhost-user-blk device supports this.
9.2
An enumeration of CPU entitlements that can be assumed by a virtual S390 CPU
8.2
An enumeration of CPU topology levels.
9.2
Caches a system may have. The enumeration value here is the combination of cache level and cache type.
9.2
Cache information for SMP system.
9.2
List wrapper of SmpCacheProperties.
Since 9.2
The comprehensive enumeration of QEMU system emulation ("softmmu") targets. Run "./configure --help" in the project root directory, and look for the *-softmmu targets near the "--target-list" option. The individual target constants are not documented here, for the time being.
NOTE:
3.0
An enumeration of cpu states that can be assumed by a virtual S390 CPU
2.12
Additional information about a virtual S390 CPU
2.12
Information about a virtual CPU
2.12
Returns information about all virtual CPUs.
list of CpuInfoFast
2.12
-> { "execute": "query-cpus-fast" } <- { "return": [ { "thread-id": 25627, "props": { "core-id": 0, "thread-id": 0, "socket-id": 0 }, "qom-path": "/machine/unattached/device[0]", "target":"x86_64", "cpu-index": 0 }, { "thread-id": 25628, "props": { "core-id": 0, "thread-id": 0, "socket-id": 1 }, "qom-path": "/machine/unattached/device[2]", "target":"x86_64", "cpu-index": 1 } ] }
Property default values specific to a machine type, for use by scripts/compare-machine-types.
9.1
Information describing a machine.
1.2
Return a list of supported machines
a list of MachineInfo
1.2
-> { "execute": "query-machines", "arguments": { "compat-props": true } } <- { "return": [ { "hotpluggable-cpus": true, "name": "pc-q35-6.2", "compat-props": [ { "qom-type": "virtio-mem", "property": "unplugged-inaccessible", "value": "off" } ], "numa-mem-supported": false, "default-cpu-type": "qemu64-x86_64-cpu", "cpu-max": 288, "deprecated": false, "default-ram-id": "pc.ram" }, ... }
Information describing the running machine parameters.
4.0
Return information on the current virtual machine.
CurrentMachineParams
4.0
Information describing the QEMU target.
1.2
Return information about the target for this QEMU
TargetInfo
1.2
Guest UUID information (Universally Unique Identifier).
0.14
NOTE:
Query the guest UUID information.
The UuidInfo for the guest
0.14
-> { "execute": "query-uuid" } <- { "return": { "UUID": "550e8400-e29b-41d4-a716-446655440000" } }
GUID information.
2.9
Show Virtual Machine Generation ID
2.9
Performs a hard reset of a guest.
0.14
Requests that a guest perform a powerdown operation.
0.14
NOTE:
Wake up guest from suspend. If the guest has wake-up from suspend support enabled (wakeup-suspend-support flag from query-current-machine), wake-up guest from suspend if the guest is in SUSPENDED state. Return an error otherwise.
1.1
NOTE:
Policy for handling lost ticks in timer devices. Ticks end up getting lost when, for example, the guest is paused.
2.0
Injects a Non-Maskable Interrupt into the default CPU (x86/s390) or all CPUs (ppc64). The command fails when the guest doesn't support injecting.
0.14
NOTE:
Information about support for KVM acceleration
0.14
Returns information about KVM acceleration
KvmInfo
0.14
2.1
A discriminated record of NUMA options. (for OptsVisitor)
2.1
Create a guest NUMA node. (for OptsVisitor)
2.1
Set the distance between 2 NUMA nodes.
2.10
Create a CXL Fixed Memory Window
7.1
List of CXL Fixed Memory Windows.
7.1
A X86 32-bit register
1.5
Information about a X86 CPU feature word
1.5
Not used by QMP; hack to let us use X86CPUFeatureWordInfoList internally
2.5
Option "-numa cpu" overrides default cpu to node mapping. It accepts the same set of cpu properties as returned by query-hotpluggable-cpus[].props, where node-id could be used to override default node mapping.
2.10
The memory hierarchy in the System Locality Latency and Bandwidth Information Structure of HMAT (Heterogeneous Memory Attribute Table)
For more information about HmatLBMemoryHierarchy, see chapter 5.2.27.4: Table 5-146: Field "Flags" of ACPI 6.3 spec.
5.0
Data type in the System Locality Latency and Bandwidth Information Structure of HMAT (Heterogeneous Memory Attribute Table)
For more information about HmatLBDataType, see chapter 5.2.27.4: Table 5-146: Field "Data Type" of ACPI 6.3 spec.
5.0
Set the system locality latency and bandwidth information between Initiator and Target proximity Domains.
For more information about NumaHmatLBOptions, see chapter 5.2.27.4: Table 5-146 of ACPI 6.3 spec.
5.0
Cache associativity in the Memory Side Cache Information Structure of HMAT
For more information of HmatCacheAssociativity, see chapter 5.2.27.5: Table 5-147 of ACPI 6.3 spec.
5.0
Cache write policy in the Memory Side Cache Information Structure of HMAT
For more information of HmatCacheWritePolicy, see chapter 5.2.27.5: Table 5-147: Field "Cache Attributes" of ACPI 6.3 spec.
5.0
Set the memory side cache information for a given memory domain.
For more information of NumaHmatCacheOptions, see chapter 5.2.27.5: Table 5-147: Field "Cache Attributes" of ACPI 6.3 spec.
5.0
Save a portion of guest memory to a file.
0.14
CAUTION:
-> { "execute": "memsave", "arguments": { "val": 10, "size": 100, "filename": "/tmp/virtual-mem-dump" } } <- { "return": {} }
Save a portion of guest physical memory to a file.
0.14
CAUTION:
-> { "execute": "pmemsave", "arguments": { "val": 10, "size": 100, "filename": "/tmp/physical-mem-dump" } } <- { "return": {} }
Information about memory backend
2.1
Returns information for all memory backends.
a list of Memdev.
2.1
-> { "execute": "query-memdev" } <- { "return": [ { "id": "mem1", "size": 536870912, "merge": false, "dump": true, "prealloc": false, "share": false, "host-nodes": [0, 1], "policy": "bind" }, { "size": 536870912, "merge": false, "dump": true, "prealloc": true, "share": false, "host-nodes": [2, 3], "policy": "preferred" } ] }
Properties identifying a CPU.
Which members are optional and which mandatory depends on the architecture and board.
For s390x see CPU topology on s390x.
The ids other than the node-id specify the position of the CPU within the CPU topology (as defined by the machine property "smp", thus see also type SMPConfiguration)
2.7
NOTE:
2.7
a list of HotpluggableCPU objects.
2.7
For pseries machine type started with -smp 2,cores=2,maxcpus=4 -cpu POWER8:
-> { "execute": "query-hotpluggable-cpus" } <- {"return": [ { "props": { "core-id": 8 }, "type": "POWER8-spapr-cpu-core", "vcpus-count": 1 }, { "props": { "core-id": 0 }, "type": "POWER8-spapr-cpu-core", "vcpus-count": 1, "qom-path": "/machine/unattached/device[0]"} ]}
For pc machine type started with -smp 1,maxcpus=2:
-> { "execute": "query-hotpluggable-cpus" } <- {"return": [ { "type": "qemu64-x86_64-cpu", "vcpus-count": 1, "props": {"core-id": 0, "socket-id": 1, "thread-id": 0} }, { "qom-path": "/machine/unattached/device[0]", "type": "qemu64-x86_64-cpu", "vcpus-count": 1, "props": {"core-id": 0, "socket-id": 0, "thread-id": 0} } ]}
For s390x-virtio-ccw machine type started with -smp 1,maxcpus=2 -cpu qemu (Since: 2.11):
-> { "execute": "query-hotpluggable-cpus" } <- {"return": [ { "type": "qemu-s390x-cpu", "vcpus-count": 1, "props": { "core-id": 1 } }, { "qom-path": "/machine/unattached/device[0]", "type": "qemu-s390x-cpu", "vcpus-count": 1, "props": { "core-id": 0 } } ]}
Runtime equivalent of '-numa' CLI option, available at preconfigure stage to configure numa mapping before initializing machine.
3.0
Request the balloon driver to change its balloon size.
From it we have: balloon_size = vm_ram_size - value
NOTE:
0.14
-> { "execute": "balloon", "arguments": { "value": 536870912 } } <- { "return": {} }
With a 2.5GiB guest this command inflated the ballon to 3GiB.
Information about the guest balloon device.
0.14
Return information about the balloon device.
BalloonInfo
0.14
Emitted when the guest changes the actual BALLOON level. This value is equivalent to the actual field return by the 'query-balloon' command
NOTE:
1.2
<- { "event": "BALLOON_CHANGE", "data": { "actual": 944766976 }, "timestamp": { "seconds": 1267020223, "microseconds": 435656 } }
hv-balloon guest-provided memory status information.
8.2
Returns the hv-balloon driver data contained in the last received "STATUS" message from the guest.
HvBalloonInfo
8.2
-> { "execute": "query-hv-balloon-status-report" } <- { "return": { "committed": 816640000, "available": 3333054464 } }
Emitted when the hv-balloon driver receives a "STATUS" message from the guest.
NOTE:
8.2
<- { "event": "HV_BALLOON_STATUS_REPORT", "data": { "committed": 816640000, "available": 3333054464 }, "timestamp": { "seconds": 1600295492, "microseconds": 661044 } }
Actual memory information in bytes.
2.11
Return the amount of initially allocated and present hotpluggable (if enabled) memory in bytes.
-> { "execute": "query-memory-size-summary" } <- { "return": { "base-memory": 4294967296, "plugged-memory": 0 } }
2.11
PCDIMMDevice state information
2.1
VirtioPMEM state information
4.1
VirtioMEMDevice state information
5.1
Sgx EPC state information
6.2
hv-balloon provided memory state information
8.2
2.1
2.1
2.1
2.1
6.2
8.2
Union containing information about a memory device
2.1
Sgx EPC cmdline information
6.2
SGX properties of machine types.
6.2
Lists available memory devices and their state
2.1
-> { "execute": "query-memory-devices" } <- { "return": [ { "data": { "addr": 5368709120, "hotpluggable": true, "hotplugged": true, "id": "d1", "memdev": "/objects/memX", "node": 0, "size": 1073741824, "slot": 0}, "type": "dimm" } ] }
Emitted when the size of a memory device changes. Only emitted for memory devices that can actually change the size (e.g., virtio-mem due to guest action).
NOTE:
5.1
<- { "event": "MEMORY_DEVICE_SIZE_CHANGE", "data": { "id": "vm0", "size": 1073741824, "qom-path": "/machine/unattached/device[2]" }, "timestamp": { "seconds": 1588168529, "microseconds": 201316 } }
Schema for virtual machine boot configuration.
7.1
Schema for CPU topology configuration. A missing value lets QEMU figure out a suitable value based on the ones that are provided.
The members other than cpus and maxcpus define a topology of containers.
The ordering from highest/coarsest to lowest/finest is: drawers, books, sockets, dies, clusters, cores, threads.
Different architectures support different subsets of topology containers.
For example, s390x does not have clusters and dies, and the socket is the parent container of cores.
6.1
Query interrupt statistics
interrupt statistics
6.2
Query TCG compiler statistics
TCG compiler statistics
6.2
CONFIG_TCG
Query NUMA topology information
topology information
6.2
Query TCG opcode counters
TCG opcode counters
6.2
CONFIG_TCG
Query system ramblock information
system ramblock information
6.2
Query information on the registered ROMS
registered ROMs
6.2
Query information on the USB devices
USB device information
6.2
7.0
Schema for memory size configuration.
7.1
Save the FDT in dtb format.
7.2
CONFIG_FDT
Query information on interrupt controller devices
Interrupt controller devices information
9.1
Virtual CPU model.
A CPU model consists of the name of a CPU definition, to which delta changes are applied (e.g. features added/removed). Most magic values that an architecture might require should be hidden behind the name. However, if required, architectures can expose relevant properties.
2.8
An enumeration of CPU model expansion types.
NOTE:
2.8
An enumeration of CPU model comparison results. The result is usually calculated using e.g. CPU features or CPU generations.
2.8
The result of a CPU model baseline.
2.8
TARGET_S390X
The result of a CPU model comparison.
responsible-properties is a list of QOM property names that led to both CPUs not being detected as identical. For identical models, this list is empty. If a QOM property is read-only, that means there's no known way to make the CPU models identical. If the special property name "type" is included, the models are by definition not identical and cannot be made identical.
2.8
TARGET_S390X
Compares two CPU models, modela and modelb, returning how they compare in a specific configuration. The results indicates how both models compare regarding runnability. This result can be used by tooling to make decisions if a certain CPU model will run in a certain configuration or if a compatible CPU model has to be created by baselining.
Usually, a CPU model is compared against the maximum possible CPU model of a certain configuration (e.g. the "host" model for KVM). If that CPU model is identical or a subset, it will run in that configuration.
The result returned by this command may be affected by:
Some architectures may not support comparing CPU models. s390x supports comparing CPU models.
a CpuModelCompareInfo describing how both CPU models compare
NOTE:
2.8
TARGET_S390X
Baseline two CPU models, modela and modelb, creating a compatible third model. The created model will always be a static, migration-safe CPU model (see "static" CPU model expansion for details).
This interface can be used by tooling to create a compatible CPU model out two CPU models. The created CPU model will be identical to or a subset of both CPU models when comparing them. Therefore, the created CPU model is guaranteed to run where the given CPU models run.
The result returned by this command may be affected by:
Some architectures may not support baselining CPU models. s390x supports baselining CPU models.
a CpuModelBaselineInfo describing the baselined CPU model
NOTE:
2.8
TARGET_S390X
The result of a cpu model expansion.
2.8
TARGET_S390X or TARGET_I386 or TARGET_ARM or TARGET_LOONGARCH64 or TARGET_RISCV
Expands a given CPU model, model, (or a combination of CPU model + additional options) to different granularities, specified by type, allowing tooling to get an understanding what a specific CPU model looks like in QEMU under a certain configuration.
This interface can be used to query the "host" CPU model.
The data returned by this command may be affected by:
Some architectures may not support all expansion types. s390x supports "full" and "static". Arm only supports "full".
a CpuModelExpansionInfo describing the expanded CPU model
2.8
TARGET_S390X or TARGET_I386 or TARGET_ARM or TARGET_LOONGARCH64 or TARGET_RISCV
Virtual CPU definition.
unavailable-features is a list of QOM property names that represent CPU model attributes that prevent the CPU from running. If the QOM property is read-only, that means there's no known way to make the CPU model run in the current host. Implementations that choose not to provide specific information return the property name "type". If the property is read-write, it means that it MAY be possible to run the CPU model in the current host if that property is changed. Management software can use it as hints to suggest or choose an alternative for the user, or just to generate meaningful error messages explaining why the CPU model can't be used. If unavailable-features is an empty list, the CPU model is runnable using the current host and machine-type. If unavailable-features is not present, runnability information for the CPU is not available.
1.2
TARGET_PPC or TARGET_ARM or TARGET_I386 or TARGET_S390X or TARGET_MIPS or TARGET_LOONGARCH64 or TARGET_RISCV
Return a list of supported virtual CPU definitions
a list of CpuDefinitionInfo
1.2
TARGET_PPC or TARGET_ARM or TARGET_I386 or TARGET_S390X or TARGET_MIPS or TARGET_LOONGARCH64 or TARGET_RISCV
An enumeration of CPU polarization that can be assumed by a virtual S390 CPU
8.2
TARGET_S390X
Modify the topology by moving the CPU inside the topology tree, or by changing a modifier attribute of a CPU. Absent values will not be modified.
8.2
TARGET_S390X and CONFIG_KVM
Emitted when the guest asks to change the polarization.
The guest can tell the host (via the PTF instruction) whether the CPUs should be provisioned using horizontal or vertical polarization.
On horizontal polarization the host is expected to provision all vCPUs equally.
On vertical polarization the host can provision each vCPU differently. The guest will get information on the details of the provisioning the next time it uses the STSI(15) instruction.
8.2
<- { "event": "CPU_POLARIZATION_CHANGE", "data": { "polarization": "horizontal" }, "timestamp": { "seconds": 1401385907, "microseconds": 422329 } }
TARGET_S390X and CONFIG_KVM
The result of a CPU polarization query.
8.2
TARGET_S390X and CONFIG_KVM
the machine's CPU polarization
8.2
TARGET_S390X and CONFIG_KVM
Mode of the replay subsystem.
2.5
Record/replay information.
5.2
Retrieve the record/replay information. It includes current instruction count which may be used for replay-break and replay-seek commands.
record/replay information.
5.2
-> { "execute": "query-replay" } <- { "return": { "mode": "play", "filename": "log.rr", "icount": 220414 } }
Set replay breakpoint at instruction count icount. Execution stops when the specified instruction is reached. There can be at most one breakpoint. When breakpoint is set, any prior one is removed. The breakpoint may be set only in replay mode and only "in the future", i.e. at instruction counts greater than the current one. The current instruction count can be observed with query-replay.
5.2
Remove replay breakpoint which was set with replay-break. The command is ignored when there are no replay breakpoints.
5.2
Automatically proceed to the instruction count icount, when replaying the execution. The command automatically loads nearest snapshot and replays the execution to find the desired instruction. When there is no preceding snapshot or the execution is not replayed, then the command fails. Instruction count can be obtained with the query-replay command.
5.2
An enumeration of yank instance types. See YankInstance for more information.
6.0
Specifies which block graph node to yank. See YankInstance for more information.
6.0
Specifies which character device to yank. See YankInstance for more information.
6.0
A yank instance can be yanked with the yank qmp command to recover from a hanging QEMU.
Currently implemented yank instances:
6.0
Try to recover from hanging QEMU by yanking the specified instances. See YankInstance for more information.
-> { "execute": "yank", "arguments": { "instances": [ { "type": "block-node", "node-name": "nbd0" } ] } } <- { "return": {} }
6.0
Query yank instances. See YankInstance for more information.
list of YankInstance
-> { "execute": "query-yank" } <- { "return": [ { "type": "block-node", "node-name": "nbd0" } ] }
6.0
Allow client connections for VNC, Spice and socket based character devices to be passed in to QEMU via SCM_RIGHTS.
If the FD associated with fdname is not a socket, the command will fail and the FD will be closed.
0.14
-> { "execute": "add_client", "arguments": { "protocol": "vnc", "fdname": "myclient" } } <- { "return": {} }
Guest name information.
0.14
Return the name information of a guest.
NameInfo of the guest
0.14
Information about an iothread
2.0
Returns a list of information about each iothread.
NOTE:
a list of IOThreadInfo for each iothread
2.0
-> { "execute": "query-iothreads" } <- { "return": [ { "id":"iothread0", "thread-id":3134 }, { "id":"iothread1", "thread-id":3135 } ] }
Stop guest VM execution.
0.14
NOTE:
In the "suspended" state, it will completely stop the VM and cause a transition to the "paused" state. (Since 9.0)
Resume guest VM execution.
0.14
NOTE:
If the VM was previously suspended, and not been reset or woken, this command will transition back to the "suspended" state. (Since 9.0)
Exit from "preconfig" state
This command makes QEMU exit the preconfig state and proceed with VM initialization using configuration data provided on the command line and via the QMP monitor during the preconfig state. The command is only available during the preconfig state (i.e. when the --preconfig command line option was in use).
3.0
Execute a command on the human monitor and return the output.
the output of the command as a string
0.14
NOTE:
Known limitations:
-> { "execute": "human-monitor-command", "arguments": { "command-line": "info kvm" } } <- { "return": "kvm support: enabled\r\n" }
Receive a file descriptor via SCM rights and assign it a name
0.14
NOTE:
The 'closefd' command can be used to explicitly close the file descriptor when it is no longer needed.
CONFIG_POSIX
Add a socket that was duplicated to QEMU process with WSADuplicateSocketW() via WSASocket() & WSAPROTOCOL_INFOW structure and assign it a name (the SOCKET is associated with a CRT file descriptor)
8.0
NOTE:
The 'closefd' command can be used to explicitly close the file descriptor when it is no longer needed.
-> { "execute": "get-win32-socket", "arguments": { "info": "abcd123..", "fdname": "skclient" } } <- { "return": {} }
CONFIG_WIN32
Close a file descriptor previously passed via SCM rights
0.14
Information about a file descriptor that was added to an fd set.
1.2
Add a file descriptor, that was passed via SCM rights, to an fd set.
AddfdInfo
NOTE:
NOTE:
1.2
-> { "execute": "add-fd", "arguments": { "fdset-id": 1 } } <- { "return": { "fdset-id": 1, "fd": 3 } }
Remove a file descriptor from an fd set.
1.2
NOTE:
NOTE:
Information about a file descriptor that belongs to an fd set.
1.2
Information about an fd set.
1.2
Return information describing all fd sets.
A list of FdsetInfo
1.2
NOTE:
-> { "execute": "query-fdsets" } <- { "return": [ { "fds": [ { "fd": 30, "opaque": "rdonly:/path/to/file" }, { "fd": 24, "opaque": "rdwr:/path/to/file" } ], "fdset-id": 1 }, { "fds": [ { "fd": 28 }, { "fd": 29 } ], "fdset-id": 0 } ] }
Possible types for an option parameter.
1.5
Details about a single parameter of a command line option.
1.5
Details about a command line option, including its list of parameter details
1.5
Query command line option schema.
list of CommandLineOptionInfo for all options (or for the given option).
1.5
-> { "execute": "query-command-line-options", "arguments": { "option": "option-rom" } } <- { "return": [ { "parameters": [ { "name": "romfile", "type": "string" }, { "name": "bootindex", "type": "number" } ], "option": "option-rom" } ] }
Emitted when the guest changes the RTC time.
NOTE:
0.13
<- { "event": "RTC_CHANGE", "data": { "offset": 78 }, "timestamp": { "seconds": 1267020223, "microseconds": 435656 } }
Emitted when the client of a TYPE_VFIO_USER_SERVER closes the communication channel
7.1
<- { "event": "VFU_CLIENT_HANGUP", "data": { "vfu-id": "vfu1", "vfu-qom-path": "/objects/vfu1", "dev-id": "sas1", "dev-qom-path": "/machine/peripheral/sas1" }, "timestamp": { "seconds": 1265044230, "microseconds": 450486 } }
This command will reset the RTC interrupt reinjection backlog. Can be used if another mechanism to synchronize guest time is in effect, for example QEMU guest agent's guest-set-time command.
2.1
TARGET_I386
An enumeration of SEV state information used during query-sev.
2.12
TARGET_I386
An enumeration indicating the type of SEV guest being run.
6.2
TARGET_I386
Information specific to legacy SEV/SEV-ES guests.
2.12
TARGET_I386
Information specific to SEV-SNP guests.
9.1
TARGET_I386
Information about Secure Encrypted Virtualization (SEV) support
2.12
TARGET_I386
Returns information about SEV
SevInfo
2.12
-> { "execute": "query-sev" } <- { "return": { "enabled": true, "api-major" : 0, "api-minor" : 0, "build-id" : 0, "policy" : 0, "state" : "running", "handle" : 1 } }
TARGET_I386
SEV Guest Launch measurement information
2.12
TARGET_I386
Query the SEV guest launch information.
The SevLaunchMeasureInfo for the guest
2.12
-> { "execute": "query-sev-launch-measure" } <- { "return": { "data": "4l8LXeNlSPUDlXPJG5966/8%YZ" } }
TARGET_I386
The struct describes capability for a Secure Encrypted Virtualization feature.
2.12
TARGET_I386
This command is used to get the SEV capabilities, and is supported on AMD X86 platforms only.
SevCapability objects.
2.12
-> { "execute": "query-sev-capabilities" } <- { "return": { "pdh": "8CCDD8DDD", "cert-chain": "888CCCDDDEE", "cpu0-id": "2lvmGwo+...61iEinw==", "cbitpos": 47, "reduced-phys-bits": 1}}
TARGET_I386
This command injects a secret blob into memory of SEV guest.
6.0
TARGET_I386
The struct describes attestation report for a Secure Encrypted Virtualization feature.
6.1
TARGET_I386
This command is used to get the SEV attestation report, and is supported on AMD X86 platforms only.
SevAttestationReport objects.
6.1
-> { "execute" : "query-sev-attestation-report", "arguments": { "mnonce": "aaaaaaa" } } <- { "return" : { "data": "aaaaaaaabbbddddd"} }
TARGET_I386
Dump guest's storage keys
2.5
-> { "execute": "dump-skeys", "arguments": { "filename": "/tmp/skeys" } } <- { "return": {} }
TARGET_S390X
The struct describes capability for a specific GIC (Generic Interrupt Controller) version. These bits are not only decided by QEMU/KVM software version, but also decided by the hardware that the program is running upon.
2.6
TARGET_ARM
This command is ARM-only. It will return a list of GICCapability objects that describe its capability bits.
a list of GICCapability objects.
2.6
-> { "execute": "query-gic-capabilities" } <- { "return": [{ "version": 2, "emulated": true, "kernel": false }, { "version": 3, "emulated": false, "kernel": true } ] }
TARGET_ARM
Information about intel SGX EPC section info
7.0
Information about intel Safe Guard eXtension (SGX) support
6.2
TARGET_I386
Returns information about SGX
SGXInfo
6.2
-> { "execute": "query-sgx" } <- { "return": { "sgx": true, "sgx1" : true, "sgx2" : true, "flc": true, "sections": [{"node": 0, "size": 67108864}, {"node": 1, "size": 29360128}]} }
TARGET_I386
Returns information from host SGX capabilities
SGXInfo
6.2
-> { "execute": "query-sgx-capabilities" } <- { "return": { "sgx": true, "sgx1" : true, "sgx2" : true, "flc": true, "section" : [{"node": 0, "size": 67108864}, {"node": 1, "size": 29360128}]} }
TARGET_I386
An enumeration of Xen event channel port types.
8.0
TARGET_I386
Information about a Xen event channel port
8.0
TARGET_I386
Query the Xen event channels opened by the guest.
list of open event channel ports.
8.0
-> { "execute": "xen-event-list" } <- { "return": [ { "pending": false, "port": 1, "vcpu": 1, "remote-domain": "qemu", "masked": false, "type": "interdomain", "target": 1 }, { "pending": false, "port": 2, "vcpu": 0, "remote-domain": "", "masked": false, "type": "virq", "target": 0 } ] }
TARGET_I386
Inject a Xen event channel port (interrupt) to the guest.
8.0
TARGET_I386
General audio backend options that are used for both playback and recording.
4.0
Generic driver-specific options.
4.0
Options of the ALSA backend that are used for both playback and recording.
4.0
Options of the ALSA audio backend.
4.0
Options of the sndio audio backend.
7.2
Options of the Core Audio backend that are used for both playback and recording.
4.0
Options of the coreaudio audio backend.
4.0
Options of the DirectSound audio backend.
4.0
Options of the JACK backend that are used for both playback and recording.
5.1
Options of the JACK audio backend.
5.1
Options of the OSS backend that are used for both playback and recording.
4.0
Options of the OSS audio backend.
4.0
Options of the Pulseaudio backend that are used for both playback and recording.
4.0
Options of the PulseAudio audio backend.
4.0
Options of the PipeWire backend that are used for both playback and recording.
8.1
Options of the PipeWire audio backend.
8.1
Options of the SDL audio backend that are used for both playback and recording.
6.0
Options of the SDL audio backend.
6.0
Options of the wav audio backend.
4.0
An enumeration of possible audio formats.
4.0
An enumeration of possible audio backend drivers.
4.0
Options of an audio backend.
4.0
Returns information about audiodev configuration
array of Audiodev
8.0
Specify an ACPI table on the command line to load.
At most one of file and data can be specified. The list of files specified by any one of them is loaded and concatenated in order. If both are omitted, data is implied.
Other fields / optargs can be used to override fields of the generic ACPI table header; refer to the ACPI specification 5.0, section 5.2.6 System Description Table Header. If a header field is not overridden, then the corresponding value from the concatenated blob is used (in case of file), or it is filled in with a hard-coded value (in case of data).
String fields are copied into the matching ACPI member from lowest address upwards, and silently truncated / NUL-padded to length.
1.5
OSPM Status Indication for a device For description of possible values of source and status fields see "_OST (OSPM Status Indication)" chapter of ACPI5.0 spec.
2.1
Return a list of ACPIOSTInfo for devices that support status reporting via ACPI _OST method.
2.1
-> { "execute": "query-acpi-ospm-status" } <- { "return": [ { "device": "d1", "slot": "0", "slot-type": "DIMM", "source": 1, "status": 0}, { "slot": "1", "slot-type": "DIMM", "source": 0, "status": 0}, { "slot": "2", "slot-type": "DIMM", "source": 0, "status": 0}, { "slot": "3", "slot-type": "DIMM", "source": 0, "status": 0} ]}
Emitted when guest executes ACPI _OST method.
2.1
<- { "event": "ACPI_DEVICE_OST", "data": { "info": { "device": "d1", "slot": "0", "slot-type": "DIMM", "source": 1, "status": 0 } }, "timestamp": { "seconds": 1265044230, "microseconds": 450486 } }
A PCI device memory region
0.14
Information about a PCI device I/O region.
0.14
Information about a bus of a PCI Bridge device
2.4
Information about a PCI Bridge device
0.14
Information about the Class of a PCI device
2.4
Information about the Id of a PCI device
2.4
Information about a PCI device
0.14
Information about a PCI bus
0.14
Return information about the PCI bus topology of the guest.
a list of PciInfo for each PCI bus. Each bus is represented by a json-object, which has a key with a json-array of all PCI devices attached to it. Each device is represented by a json-object.
0.14
-> { "execute": "query-pci" } <- { "return": [ { "bus": 0, "devices": [ { "bus": 0, "qdev_id": "", "slot": 0, "class_info": { "class": 1536, "desc": "Host bridge" }, "id": { "device": 32902, "vendor": 4663 }, "function": 0, "regions": [ ] }, { "bus": 0, "qdev_id": "", "slot": 1, "class_info": { "class": 1537, "desc": "ISA bridge" }, "id": { "device": 32902, "vendor": 28672 }, "function": 0, "regions": [ ] }, { "bus": 0, "qdev_id": "", "slot": 1, "class_info": { "class": 257, "desc": "IDE controller" }, "id": { "device": 32902, "vendor": 28688 }, "function": 1, "regions": [ { "bar": 4, "size": 16, "address": 49152, "type": "io" } ] }, { "bus": 0, "qdev_id": "", "slot": 2, "class_info": { "class": 768, "desc": "VGA controller" }, "id": { "device": 4115, "vendor": 184 }, "function": 0, "regions": [ { "prefetch": true, "mem_type_64": false, "bar": 0, "size": 33554432, "address": 4026531840, "type": "memory" }, { "prefetch": false, "mem_type_64": false, "bar": 1, "size": 4096, "address": 4060086272, "type": "memory" }, { "prefetch": false, "mem_type_64": false, "bar": 6, "size": 65536, "address": -1, "type": "memory" } ] }, { "bus": 0, "qdev_id": "", "irq": 11, "slot": 4, "class_info": { "class": 1280, "desc": "RAM controller" }, "id": { "device": 6900, "vendor": 4098 }, "function": 0, "regions": [ { "bar": 0, "size": 32, "address": 49280, "type": "io" } ] } ] } ] }
This example has been shortened as the real response is too long.
Enumeration of statistics types
7.1
Enumeration of unit of measurement for statistics
7.1
Enumeration of statistics providers.
7.1
The kinds of objects on which one can request statistics.
7.1
Indicates a set of statistics that should be returned by query-stats.
7.1
7.1
The arguments to the query-stats command; specifies a target for which to request statistics and optionally the required subset of information for that target.
7.1
7.1
7.1
7.1
Return runtime-collected statistics for objects such as the VM or its vCPUs.
The arguments are a StatsFilter and specify the provider and objects to return statistics about.
a list of StatsResult, one for each provider and object (e.g., for each vCPU).
7.1
Schema for a single statistic.
7.1
Schema for all available statistics for a provider and target.
7.1
Return the schema for all available runtime-collected statistics.
NOTE:
7.1
Basic information about a given VirtIODevice
7.2
Returns a list of all realized VirtIODevices
List of gathered VirtIODevices
7.2
-> { "execute": "x-query-virtio" } <- { "return": [ { "name": "virtio-input", "path": "/machine/peripheral-anon/device[4]/virtio-backend" }, { "name": "virtio-crypto", "path": "/machine/peripheral/crypto0/virtio-backend" }, { "name": "virtio-scsi", "path": "/machine/peripheral-anon/device[2]/virtio-backend" }, { "name": "virtio-net", "path": "/machine/peripheral-anon/device[1]/virtio-backend" }, { "name": "virtio-serial", "path": "/machine/peripheral-anon/device[0]/virtio-backend" } ] }
Information about a vhost device. This information will only be displayed if the vhost device is active.
7.2
Full status of the virtio device with most VirtIODevice members. Also includes the full status of the corresponding vhost device if the vhost device is active.
7.2
Poll for a comprehensive status of a given virtio device
VirtioStatus of the virtio device
7.2
Poll for the status of virtio-crypto (no vhost-crypto active)
-> { "execute": "x-query-virtio-status", "arguments": { "path": "/machine/peripheral/crypto0/virtio-backend" } } <- { "return": { "device-endian": "little", "bus-name": "", "disable-legacy-check": false, "name": "virtio-crypto", "started": true, "device-id": 20, "backend-features": { "transports": [], "dev-features": [] }, "start-on-kick": false, "isr": 1, "broken": false, "status": { "statuses": [ "VIRTIO_CONFIG_S_ACKNOWLEDGE: Valid virtio device found", "VIRTIO_CONFIG_S_DRIVER: Guest OS compatible with device", "VIRTIO_CONFIG_S_FEATURES_OK: Feature negotiation complete", "VIRTIO_CONFIG_S_DRIVER_OK: Driver setup and ready" ] }, "num-vqs": 2, "guest-features": { "dev-features": [], "transports": [ "VIRTIO_RING_F_EVENT_IDX: Used & avail. event fields enabled", "VIRTIO_RING_F_INDIRECT_DESC: Indirect descriptors supported", "VIRTIO_F_VERSION_1: Device compliant for v1 spec (legacy)" ] }, "host-features": { "unknown-dev-features": 1073741824, "dev-features": [], "transports": [ "VIRTIO_RING_F_EVENT_IDX: Used & avail. event fields enabled", "VIRTIO_RING_F_INDIRECT_DESC: Indirect descriptors supported", "VIRTIO_F_VERSION_1: Device compliant for v1 spec (legacy)", "VIRTIO_F_ANY_LAYOUT: Device accepts arbitrary desc. layouts", "VIRTIO_F_NOTIFY_ON_EMPTY: Notify when device runs out of avail. descs. on VQ" ] }, "use-guest-notifier-mask": true, "vm-running": true, "queue-sel": 1, "disabled": false, "vhost-started": false, "use-started": true } }
Poll for the status of virtio-net (vhost-net is active)
-> { "execute": "x-query-virtio-status", "arguments": { "path": "/machine/peripheral-anon/device[1]/virtio-backend" } } <- { "return": { "device-endian": "little", "bus-name": "", "disabled-legacy-check": false, "name": "virtio-net", "started": true, "device-id": 1, "vhost-dev": { "n-tmp-sections": 4, "n-mem-sections": 4, "max-queues": 1, "backend-cap": 2, "log-size": 0, "backend-features": { "dev-features": [], "transports": [] }, "nvqs": 2, "protocol-features": { "protocols": [] }, "vq-index": 0, "log-enabled": false, "acked-features": { "dev-features": [ "VIRTIO_NET_F_MRG_RXBUF: Driver can merge receive buffers" ], "transports": [ "VIRTIO_RING_F_EVENT_IDX: Used & avail. event fields enabled", "VIRTIO_RING_F_INDIRECT_DESC: Indirect descriptors supported", "VIRTIO_F_VERSION_1: Device compliant for v1 spec (legacy)" ] }, "features": { "dev-features": [ "VHOST_F_LOG_ALL: Logging write descriptors supported", "VIRTIO_NET_F_MRG_RXBUF: Driver can merge receive buffers" ], "transports": [ "VIRTIO_RING_F_EVENT_IDX: Used & avail. event fields enabled", "VIRTIO_RING_F_INDIRECT_DESC: Indirect descriptors supported", "VIRTIO_F_IOMMU_PLATFORM: Device can be used on IOMMU platform", "VIRTIO_F_VERSION_1: Device compliant for v1 spec (legacy)", "VIRTIO_F_ANY_LAYOUT: Device accepts arbitrary desc. layouts", "VIRTIO_F_NOTIFY_ON_EMPTY: Notify when device runs out of avail. descs. on VQ" ] } }, "backend-features": { "dev-features": [ "VHOST_USER_F_PROTOCOL_FEATURES: Vhost-user protocol features negotiation supported", "VIRTIO_NET_F_GSO: Handling GSO-type packets supported", "VIRTIO_NET_F_CTRL_MAC_ADDR: MAC address set through control channel", "VIRTIO_NET_F_GUEST_ANNOUNCE: Driver sending gratuitous packets supported", "VIRTIO_NET_F_CTRL_RX_EXTRA: Extra RX mode control supported", "VIRTIO_NET_F_CTRL_VLAN: Control channel VLAN filtering supported", "VIRTIO_NET_F_CTRL_RX: Control channel RX mode supported", "VIRTIO_NET_F_CTRL_VQ: Control channel available", "VIRTIO_NET_F_STATUS: Configuration status field available", "VIRTIO_NET_F_MRG_RXBUF: Driver can merge receive buffers", "VIRTIO_NET_F_HOST_UFO: Device can receive UFO", "VIRTIO_NET_F_HOST_ECN: Device can receive TSO with ECN", "VIRTIO_NET_F_HOST_TSO6: Device can receive TSOv6", "VIRTIO_NET_F_HOST_TSO4: Device can receive TSOv4", "VIRTIO_NET_F_GUEST_UFO: Driver can receive UFO", "VIRTIO_NET_F_GUEST_ECN: Driver can receive TSO with ECN", "VIRTIO_NET_F_GUEST_TSO6: Driver can receive TSOv6", "VIRTIO_NET_F_GUEST_TSO4: Driver can receive TSOv4", "VIRTIO_NET_F_MAC: Device has given MAC address", "VIRTIO_NET_F_CTRL_GUEST_OFFLOADS: Control channel offloading reconfig. supported", "VIRTIO_NET_F_GUEST_CSUM: Driver handling packets with partial checksum supported", "VIRTIO_NET_F_CSUM: Device handling packets with partial checksum supported" ], "transports": [ "VIRTIO_RING_F_EVENT_IDX: Used & avail. event fields enabled", "VIRTIO_RING_F_INDIRECT_DESC: Indirect descriptors supported", "VIRTIO_F_VERSION_1: Device compliant for v1 spec (legacy)", "VIRTIO_F_ANY_LAYOUT: Device accepts arbitrary desc. layouts", "VIRTIO_F_NOTIFY_ON_EMPTY: Notify when device runs out of avail. descs. on VQ" ] }, "start-on-kick": false, "isr": 1, "broken": false, "status": { "statuses": [ "VIRTIO_CONFIG_S_ACKNOWLEDGE: Valid virtio device found", "VIRTIO_CONFIG_S_DRIVER: Guest OS compatible with device", "VIRTIO_CONFIG_S_FEATURES_OK: Feature negotiation complete", "VIRTIO_CONFIG_S_DRIVER_OK: Driver setup and ready" ] }, "num-vqs": 3, "guest-features": { "dev-features": [ "VIRTIO_NET_F_CTRL_MAC_ADDR: MAC address set through control channel", "VIRTIO_NET_F_GUEST_ANNOUNCE: Driver sending gratuitous packets supported", "VIRTIO_NET_F_CTRL_VLAN: Control channel VLAN filtering supported", "VIRTIO_NET_F_CTRL_RX: Control channel RX mode supported", "VIRTIO_NET_F_CTRL_VQ: Control channel available", "VIRTIO_NET_F_STATUS: Configuration status field available", "VIRTIO_NET_F_MRG_RXBUF: Driver can merge receive buffers", "VIRTIO_NET_F_HOST_UFO: Device can receive UFO", "VIRTIO_NET_F_HOST_ECN: Device can receive TSO with ECN", "VIRTIO_NET_F_HOST_TSO6: Device can receive TSOv6", "VIRTIO_NET_F_HOST_TSO4: Device can receive TSOv4", "VIRTIO_NET_F_GUEST_UFO: Driver can receive UFO", "VIRTIO_NET_F_GUEST_ECN: Driver can receive TSO with ECN", "VIRTIO_NET_F_GUEST_TSO6: Driver can receive TSOv6", "VIRTIO_NET_F_GUEST_TSO4: Driver can receive TSOv4", "VIRTIO_NET_F_MAC: Device has given MAC address", "VIRTIO_NET_F_CTRL_GUEST_OFFLOADS: Control channel offloading reconfig. supported", "VIRTIO_NET_F_GUEST_CSUM: Driver handling packets with partial checksum supported", "VIRTIO_NET_F_CSUM: Device handling packets with partial checksum supported" ], "transports": [ "VIRTIO_RING_F_EVENT_IDX: Used & avail. event fields enabled", "VIRTIO_RING_F_INDIRECT_DESC: Indirect descriptors supported", "VIRTIO_F_VERSION_1: Device compliant for v1 spec (legacy)" ] }, "host-features": { "dev-features": [ "VHOST_USER_F_PROTOCOL_FEATURES: Vhost-user protocol features negotiation supported", "VIRTIO_NET_F_GSO: Handling GSO-type packets supported", "VIRTIO_NET_F_CTRL_MAC_ADDR: MAC address set through control channel", "VIRTIO_NET_F_GUEST_ANNOUNCE: Driver sending gratuitous packets supported", "VIRTIO_NET_F_CTRL_RX_EXTRA: Extra RX mode control supported", "VIRTIO_NET_F_CTRL_VLAN: Control channel VLAN filtering supported", "VIRTIO_NET_F_CTRL_RX: Control channel RX mode supported", "VIRTIO_NET_F_CTRL_VQ: Control channel available", "VIRTIO_NET_F_STATUS: Configuration status field available", "VIRTIO_NET_F_MRG_RXBUF: Driver can merge receive buffers", "VIRTIO_NET_F_HOST_UFO: Device can receive UFO", "VIRTIO_NET_F_HOST_ECN: Device can receive TSO with ECN", "VIRTIO_NET_F_HOST_TSO6: Device can receive TSOv6", "VIRTIO_NET_F_HOST_TSO4: Device can receive TSOv4", "VIRTIO_NET_F_GUEST_UFO: Driver can receive UFO", "VIRTIO_NET_F_GUEST_ECN: Driver can receive TSO with ECN", "VIRTIO_NET_F_GUEST_TSO6: Driver can receive TSOv6", "VIRTIO_NET_F_GUEST_TSO4: Driver can receive TSOv4", "VIRTIO_NET_F_MAC: Device has given MAC address", "VIRTIO_NET_F_CTRL_GUEST_OFFLOADS: Control channel offloading reconfig. supported", "VIRTIO_NET_F_GUEST_CSUM: Driver handling packets with partial checksum supported", "VIRTIO_NET_F_CSUM: Device handling packets with partial checksum supported" ], "transports": [ "VIRTIO_RING_F_EVENT_IDX: Used & avail. event fields enabled", "VIRTIO_RING_F_INDIRECT_DESC: Indirect descriptors supported", "VIRTIO_F_VERSION_1: Device compliant for v1 spec (legacy)", "VIRTIO_F_ANY_LAYOUT: Device accepts arbitrary desc. layouts", "VIRTIO_F_NOTIFY_ON_EMPTY: Notify when device runs out of avail. descs. on VQ" ] }, "use-guest-notifier-mask": true, "vm-running": true, "queue-sel": 2, "disabled": false, "vhost-started": true, "use-started": true } }
A structure defined to list the configuration statuses of a virtio device
7.2
A structure defined to list the vhost user protocol features of a Vhost User device
7.2
The common fields that apply to most Virtio devices. Some devices may not have their own device-specific features (e.g. virtio-rng).
7.2
Information of a VirtIODevice VirtQueue, including most members of the VirtQueue data structure.
7.2
Return the status of a given VirtIODevice's VirtQueue
VirtQueueStatus of the VirtQueue
NOTE:
7.2
Get VirtQueueStatus for virtio-vsock (vhost-vsock running)
-> { "execute": "x-query-virtio-queue-status", "arguments": { "path": "/machine/peripheral/vsock0/virtio-backend", "queue": 1 } } <- { "return": { "signalled-used": 0, "inuse": 0, "name": "vhost-vsock", "vring-align": 4096, "vring-desc": 5217370112, "signalled-used-valid": false, "vring-num-default": 128, "vring-avail": 5217372160, "queue-index": 1, "last-avail-idx": 0, "vring-used": 5217372480, "used-idx": 0, "vring-num": 128 } }
Get VirtQueueStatus for virtio-serial (no vhost)
-> { "execute": "x-query-virtio-queue-status", "arguments": { "path": "/machine/peripheral-anon/device[0]/virtio-backend", "queue": 20 } } <- { "return": { "signalled-used": 0, "inuse": 0, "name": "virtio-serial", "vring-align": 4096, "vring-desc": 5182074880, "signalled-used-valid": false, "vring-num-default": 128, "vring-avail": 5182076928, "queue-index": 20, "last-avail-idx": 0, "vring-used": 5182077248, "used-idx": 0, "shadow-avail-idx": 0, "vring-num": 128 } }
Information of a vhost device's vhost_virtqueue, including most members of the vhost_dev vhost_virtqueue data structure.
7.2
Return information of a given vhost device's vhost_virtqueue
VirtVhostQueueStatus of the vhost_virtqueue
7.2
-> { "execute": "x-query-virtio-vhost-queue-status", "arguments": { "path": "/machine/peripheral/crypto0/virtio-backend", "queue": 0 } } <- { "return": { "avail-phys": 5216124928, "name": "virtio-crypto", "used-phys": 5216127040, "avail-size": 2054, "desc-size": 16384, "used-size": 8198, "desc": 140141447430144, "num": 1024, "call": 0, "avail": 140141447446528, "desc-phys": 5216108544, "used": 140141447448640, "kick": 0 } }
-> { "execute": "x-query-virtio-vhost-queue-status", "arguments": { "path": "/machine/peripheral/vsock0/virtio-backend", "queue": 0 } } <- { "return": { "avail-phys": 5182261248, "name": "vhost-vsock", "used-phys": 5182261568, "avail-size": 262, "desc-size": 2048, "used-size": 1030, "desc": 140141413580800, "num": 128, "call": 0, "avail": 140141413582848, "desc-phys": 5182259200, "used": 140141413583168, "kick": 0 } }
Information regarding the vring descriptor area
7.2
Information regarding the avail vring (a.k.a. driver area)
7.2
Information regarding the used vring (a.k.a. device area)
7.2
Information regarding a VirtQueue's VirtQueueElement including descriptor, driver, and device areas
7.2
Return the information about a VirtQueue's VirtQueueElement
VirtioQueueElement information
7.2
-> { "execute": "x-query-virtio-queue-element", "arguments": { "path": "/machine/peripheral-anon/device[1]/virtio-backend", "queue": 0, "index": 5 } } <- { "return": { "index": 5, "name": "virtio-net", "descs": [ { "flags": ["write"], "len": 1536, "addr": 5257305600 } ], "avail": { "idx": 256, "flags": 0, "ring": 5 }, "used": { "idx": 13, "flags": 0 } } }
-> { "execute": "x-query-virtio-queue-element", "arguments": { "path": "/machine/peripheral/crypto0/virtio-backend", "queue": 1 } } <- { "return": { "index": 0, "name": "virtio-crypto", "descs": [ { "flags": [], "len": 0, "addr": 8080268923184214134 } ], "avail": { "idx": 280, "flags": 0, "ring": 0 }, "used": { "idx": 280, "flags": 0 } } }
-> { "execute": "x-query-virtio-queue-element", "arguments": { "path": "/machine/peripheral-anon/device[2]/virtio-backend", "queue": 2 } } <- { "return": { "index": 19, "name": "virtio-scsi", "descs": [ { "flags": ["used", "indirect", "write"], "len": 4099327944, "addr": 12055409292258155293 } ], "avail": { "idx": 1147, "flags": 0, "ring": 19 }, "used": { "idx": 280, "flags": 0 } } }
Describes the subset of virtqueues assigned to an IOThread.
9.0
Not used by QMP; hack to let us use IOThreadVirtQueueMappingList internally
9.0
9.0
An enumeration of the VFIO device migration states.
9.1
This event is emitted when a VFIO device migration state is changed.
9.1
<- { "timestamp": { "seconds": 1713771323, "microseconds": 212268 }, "event": "VFIO_MIGRATION", "data": { "device-id": "vfio_dev1", "qom-path": "/machine/peripheral/vfio_dev1", "device-state": "stop" } }
The supported algorithm types of a crypto device.
8.0
The supported service types of a crypto device.
8.0
The crypto device backend type
8.0
Information about a queue of crypto device.
8.0
Information about a crypto device.
8.0
Returns information about current crypto devices.
a list of QCryptodevInfo
8.0
CXL has a number of separate event logs for different types of events. Each such event log is handled and signaled independently.
8.1
Inject an event record for a General Media Event (CXL r3.0 8.2.9.2.1.1). This event type is reported via one of the event logs specified via the log parameter.
8.1
Inject an event record for a DRAM Event (CXL r3.0 8.2.9.2.1.2). This event type is reported via one of the event logs specified via the log parameter.
8.1
Inject an event record for a Memory Module Event (CXL r3.0 8.2.9.2.1.3). This event includes a copy of the Device Health info at the time of the event.
8.1
Poison records indicate that a CXL memory device knows that a particular memory region may be corrupted. This may be because of locally detected errors (e.g. ECC failure) or poisoned writes received from other components in the system. This injection mechanism enables testing of the OS handling of poison records which may be queried via the CXL mailbox.
8.1
Type of uncorrectable CXL error to inject. These errors are reported via an AER uncorrectable internal error with additional information logged at the CXL device.
8.0
Record of a single error including header log.
8.0
Command to allow injection of multiple errors in one go. This allows testing of multiple header log handling in the OS.
8.0
Type of CXL correctable error to inject
8.0
Command to inject a single correctable error. Multiple error injection of this error type is not interesting as there is no associated header log. These errors are reported via AER as a correctable internal error, with additional detail available from the CXL device.
8.0
A single dynamic capacity extent. This is a contiguous allocation of memory by Device Physical Address within a single Dynamic Capacity Region on a CXL Type 3 Device.
9.1
The policy to use for selecting which extents comprise the added capacity, as defined in Compute Express Link (CXL) Specification, Revision 3.1, Table 7-70.
9.1
Initiate adding dynamic capacity extents to a host. This simulates operations defined in Compute Express Link (CXL) Specification, Revision 3.1, Section 7.6.7.6.5. Note that, currently, establishing success or failure of the full Add Dynamic Capacity flow requires out of band communication with the OS of the CXL host.
Since : 9.1
The policy to use for selecting which extents comprise the released capacity, defined in the "Flags" field in Compute Express Link (CXL) Specification, Revision 3.1, Table 7-71.
9.1
Initiate release of dynamic capacity extents from a host. This simulates operations defined in Compute Express Link (CXL) Specification, Revision 3.1, Section 7.6.7.6.6. Note that, currently, success or failure of the full Release Dynamic Capacity flow requires out of band communication with the OS of the CXL host.
Since : 9.1
2024, The QEMU Project Developers
January 12, 2025 | 9.2.0 |