| QEMU-QMP-REF(7) | QEMU | QEMU-QMP-REF(7) |
qemu-qmp-ref - QEMU QMP Reference Manual
This manual describes the commands and events supported by the QEMU Monitor Protocol (QMP).
For locating a particular item, please see the QMP Index.
The following notation is used in examples:
-> ... text sent by client (commands) ... <- ... text sent by server (command responses and events) ...
Example text is formatted for readability. However, in real protocol usage, its commonly emitted as a single line.
Please refer to the QEMU Machine Protocol Specification for the general format of commands, responses, and events.
NOTE:
NOTE:
<- { "event": "SHUTDOWN",
"data": { "guest": true, "reason": "guest-shutdown" },
"timestamp": { "seconds": 1267040730, "microseconds": 682951 } }
<- { "event": "POWERDOWN",
"timestamp": { "seconds": 1267040730, "microseconds": 682951 } }
<- { "event": "RESET",
"data": { "guest": false, "reason": "guest-reset" },
"timestamp": { "seconds": 1267041653, "microseconds": 9518 } }
NOTE:
<- { "event": "SUSPEND_DISK",
"timestamp": { "seconds": 1344456160, "microseconds": 309119 } }
NOTE:
NOTE:
<- { "event": "WATCHDOG",
"data": { "action": "reset" },
"timestamp": { "seconds": 1267061043, "microseconds": 959568 } }
-> { "execute": "watchdog-set-action",
"arguments": { "action": "inject-nmi" } }
<- { "return": {} }
-> { "execute": "set-action",
"arguments": { "reboot": "shutdown",
"shutdown" : "pause",
"panic": "pause",
"watchdog": "inject-nmi" } }
<- { "return": {} }
<- { "event": "GUEST_PANICKED",
"data": { "action": "pause" },
"timestamp": { "seconds": 1648245231, "microseconds": 900001 } }
<- { "event": "GUEST_CRASHLOADED",
"data": { "action": "run" },
"timestamp": { "seconds": 1648245259, "microseconds": 893771 } }
<- { "event": "GUEST_PVSHUTDOWN",
"timestamp": { "seconds": 1648245259, "microseconds": 893771 } }
<- { "event": "MEMORY_FAILURE",
"data": { "recipient": "hypervisor",
"action": "fatal",
"flags": { "action-required": false,
"recursive": false } },
"timestamp": { "seconds": 1267061043, "microseconds": 959568 } }
Optional. ID of the keyslot to activate/deactivate. For keyslot activation, keyslot should not be active already (this is unsafe to update an active keyslot), but possible if 'force' parameter is given. If keyslot is not given, first free keyslot will be written.
For keyslot deactivation, this parameter specifies the exact keyslot to deactivate
Either data or file must be provided, but not both.
Properties for secret_keyring objects.
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.
This command returns immediately after resuming a paused job. Resuming an already running job is an error.
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.
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.
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.
If this field is present, the job failed; if it is still missing in the CONCLUDED state, this indicates successful completion.
The value is a human-readable error message to describe the reason for the job failure. It should not be parsed by applications.
list of io request counts corresponding to histogram intervals, one more element than boundaries has. For the example above, bins may be something like [3, 1, 5, 2], and corresponding histogram looks like:
5| * 4| * 3| * * 2| * * * 1| * * * *
+------------------
10 50 100
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.
-> { "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"
}
]
}
-> { "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
}
}
]
}
Either device or node-name must be set but not both.
-> { "execute": "block_resize",
"arguments": { "device": "scratch", "size": 1073741824 } }
<- { "return": {} }
NOTE:
-> { "execute": "blockdev-snapshot-sync",
"arguments": { "device": "ide-hd0",
"snapshot-file":
"/some/place/my-image",
"format": "qcow2" } }
<- { "return": {} }
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.
-> { "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": {} }
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.
The backing file string to write into the overlay image of 'top'. If 'top' does not have an overlay image, or if 'top' is in use by a writer, specifying a backing file string is an error.
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)
-> { "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.
-> { "execute": "drive-backup",
"arguments": { "device": "drive0",
"sync": "full",
"target": "backup.img" } }
<- { "return": {} }
-> { "execute": "blockdev-backup",
"arguments": { "device": "src-id",
"sync": "full",
"target": "tgt-id" } }
<- { "return": {} }
-> { "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
}
} } ] }
Get the block graph.
-> { "execute": "drive-mirror",
"arguments": { "device": "ide-hd0",
"target": "/some/place/my-image",
"sync": "full",
"format": "qcow2" } }
<- { "return": {} }
-> { "execute": "block-dirty-bitmap-add",
"arguments": { "node": "drive0", "name": "bitmap0" } }
<- { "return": {} }
-> { "execute": "block-dirty-bitmap-remove",
"arguments": { "node": "drive0", "name": "bitmap0" } }
<- { "return": {} }
-> { "execute": "block-dirty-bitmap-clear",
"arguments": { "node": "drive0", "name": "bitmap0" } }
<- { "return": {} }
-> { "execute": "block-dirty-bitmap-enable",
"arguments": { "node": "drive0", "name": "bitmap0" } }
<- { "return": {} }
-> { "execute": "block-dirty-bitmap-disable",
"arguments": { "node": "drive0", "name": "bitmap0" } }
<- { "return": {} }
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.
-> { "execute": "block-dirty-bitmap-merge",
"arguments": { "node": "drive0", "target": "bitmap0",
"bitmaps": ["bitmap1"] } }
<- { "return": {} }
Get bitmap SHA256.
-> { "execute": "blockdev-mirror",
"arguments": { "device": "ide-hd0",
"target": "target0",
"sync": "full" } }
<- { "return": {} }
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.
The backing file string to write into the top image. 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)
-> { "execute": "block-stream",
"arguments": { "device": "virtio0",
"base": "/tmp/master.qcow2" } }
<- { "return": {} }
This command can only be issued when there is an active block job.
Throttling can be disabled by setting the speed to 0.
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.
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.
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.
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.
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.
Note that the PCI device must have been unbound from any host kernel driver before instructing QEMU to add the blockdev.
Driver specific block device options for the io_uring backend.
Driver specific block device options for the nvme-io_uring backend.
Driver specific block device options for the virtio-blk-vfio-pci backend.
Driver specific block device options for the virtio-blk-vhost-user backend.
Driver specific block device options for the virtio-blk-vhost-vdpa backend.
An enumeration of replication modes.
Driver specific block device options for replication
-> { "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": {} }
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.
-> { "execute": "blockdev-add",
"arguments": {
"driver": "qcow2",
"node-name": "node0",
"file": {
"driver": "file",
"filename": "test.qcow2"
}
}
}
<- { "return": {} }
-> { "execute": "blockdev-del",
"arguments": { "node-name": "node0" }
}
<- { "return": {} }
Activating a node automatically activates all of its child nodes first. Inactivating a node automatically inactivates any of its child nodes that are not in use by a still active node.
-> { "execute": "blockdev-set-active",
"arguments": {
"node-name": "node0",
"active": false
}
}
<- { "return": {} }
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.
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 } }
NOTE:
NOTE:
<- { "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 } }
<- { "event": "BLOCK_JOB_COMPLETED",
"data": { "type": "stream", "device": "virtio-disk0",
"len": 10737418240, "offset": 10737418240,
"speed": 0 },
"timestamp": { "seconds": 1267061043, "microseconds": 959568 } }
<- { "event": "BLOCK_JOB_CANCELLED",
"data": { "type": "stream", "device": "virtio-disk0",
"len": 10737418240, "offset": 134217728,
"speed": 0 },
"timestamp": { "seconds": 1267061043, "microseconds": 959568 } }
<- { "event": "BLOCK_JOB_ERROR",
"data": { "device": "ide0-hd1",
"operation": "write",
"action": "stop" },
"timestamp": { "seconds": 1265044230, "microseconds": 450486 } }
NOTE:
<- { "event": "BLOCK_JOB_READY",
"data": { "device": "drive0", "type": "mirror", "speed": 0,
"len": 2097152, "offset": 2097152 },
"timestamp": { "seconds": 1265044230, "microseconds": 450486 } }
<- { "event": "BLOCK_JOB_PENDING",
"data": { "type": "mirror", "id": "backup_1" },
"timestamp": { "seconds": 1265044230, "microseconds": 450486 } }
This is useful to transparently resize thin-provisioned drives without the guest OS noticing.
-> { "execute": "block-set-write-threshold",
"arguments": { "node-name": "mydev",
"write-threshold": 17179869184 } }
<- { "return": {} }
Dynamically reconfigure the block driver state graph.
Currently only supports adding and deleting quorum children. A child will be added at the end of the list of children. Its contents must be consistent with the other childrens' contents. Deleting a child that is not last in the list of children is problematic, because it "renumbers" the children following it.
-> { "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.
-> { "execute": "x-blockdev-set-iothread",
"arguments": { "node-name": "disk1",
"iothread": "iothread0" } }
<- { "return": {} }
-> { "execute": "x-blockdev-set-iothread",
"arguments": { "node-name": "disk1",
"iothread": null } }
<- { "return": {} }
NOTE:
<- { "event": "QUORUM_FAILURE",
"data": { "reference": "usr1", "sector-num": 345435, "sectors-count": 5 },
"timestamp": { "seconds": 1344522075, "microseconds": 745528 } }
NOTE:
<- { "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 } }
NOTE:
-> { "execute": "blockdev-snapshot-internal-sync",
"arguments": { "device": "ide-hd0",
"name": "snapshot0" }
}
<- { "return": {} }
-> { "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
}
}
NOTE:
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:
-> { "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": {} }
If the tray was already closed before, this will be a no-op.
-> { "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": {} }
If the tray is open and there is no medium inserted, this will be a no-op.
-> { "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": {} }
-> { "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": {} }
-> { "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": {} }
<- { "event": "DEVICE_TRAY_MOVED",
"data": { "device": "ide1-cd0",
"id": "/machine/unattached/device[22]",
"tray-open": true
},
"timestamp": { "seconds": 1265044230, "microseconds": 450486 } }
<- { "event": "PR_MANAGER_STATUS_CHANGED",
"data": { "id": "pr-helper0",
"connected": true
},
"timestamp": { "seconds": 1519840375, "microseconds": 450486 } }
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.
-> { "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": {} }
If only id parameter is specified, remove all present latency histograms for the device. Otherwise, add/reset some of (or all) latency histograms.
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": {} }
Options for exporting a block graph node on some (file) mountpoint as a raw image.
Export a block node to QEMU's embedded NBD server.
The export name will be used as the id for the resulting block export.
Remove NBD export by name.
NOTE:
-> { "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
}
]
}
-> { "execute": "query-chardev-backends" }
<- {
"return":[
{
"name":"udp"
},
{
"name":"tcp"
},
{
"name":"unix"
},
{
"name":"spiceport"
}
]
}
data encoding (default 'utf8').
-> { "execute": "ringbuf-write",
"arguments": { "device": "foo",
"data": "abcdefgh",
"format": "utf8" } }
<- { "return": {} }
data encoding (default 'utf8').
-> { "execute": "ringbuf-read",
"arguments": { "device": "foo",
"size": 1000,
"format": "utf8" } }
<- { "return": "abcdefgh" }
Configuration info for spice vm channel chardevs.
Configuration info for spice port chardevs.
Configuration info for DBus chardevs.
NOTE:
Configuration info for qemu vdagent implementation.
-> { "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" } }
-> { "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": {}}
NOTE:
<- { "event": "VSERPORT_CHANGE",
"data": { "id": "channel0", "open": true },
"timestamp": { "seconds": 1401385907, "microseconds": 422329 } }
if true, do paging to get guest's memory mapping. This allows using gdb to process the core file.
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:
the filename or file descriptor of the vmcore. The supported protocols are:
NOTE:
-> { "execute": "dump-guest-memory",
"arguments": { "paging": false, "protocol": "fd:dump" } }
<- { "return": {} }
-> { "execute": "query-dump" }
<- { "return": { "status": "active", "completed": 1024000,
"total": 2048000 } }
<- { "event": "DUMP_COMPLETED",
"data": { "result": { "total": 1090650112, "status": "completed",
"completed": 1090650112 } },
"timestamp": { "seconds": 1648244171, "microseconds": 950316 } }
-> { "execute": "query-dump-guest-memory-capability" }
<- { "return": { "formats":
["elf", "kdump-zlib", "kdump-lzo", "kdump-snappy"] } }
NOTE:
-> { "execute": "set_link",
"arguments": { "name": "e1000.0", "up": false } }
<- { "return": {} }
Additional arguments depend on the type.
-> { "execute": "netdev_add",
"arguments": { "type": "user", "id": "netdev1",
"dnssearch": [ { "str": "example.org" } ] } }
<- { "return": {} }
Attach mode for a default XDP program
AF_XDP network backend
vDPA device is a device that uses a datapath which complies with the virtio specifications with a vendor specific control path.
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.
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.
vmnet (bridged mode) network backend.
Bridges the vmnet interface with a physical network interface.
Only SocketAddress types 'unix', 'inet' and 'fd' are supported.
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 |
-> { "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
}
]
}
<- { "event": "NIC_RX_FILTER_CHANGED",
"data": { "name": "vnet0",
"path": "/machine/peripheral/vnet0/virtio-backend" },
"timestamp": { "seconds": 1368697518, "microseconds": 326866 } }
-> { "execute": "announce-self",
"arguments": {
"initial": 50, "max": 550, "rounds": 10, "step": 50,
"interfaces": ["vn2", "vn3"], "id": "bob" } }
<- { "return": {} }
<- { "event": "FAILOVER_NEGOTIATED",
"data": { "device-id": "net1" },
"timestamp": { "seconds": 1368697518, "microseconds": 326866 } }
<- { "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 } }
<- { "event": "NETDEV_STREAM_DISCONNECTED",
"data": {"netdev-id": "netdev0"},
"timestamp": {"seconds": 1663330937, "microseconds": 526695} }
<- { "timestamp": {"seconds": 1739538638, "microseconds": 354181 },
"event": "NETDEV_VHOST_USER_CONNECTED",
"data": { "netdev-id": "netdev0", "chardev-id": "chr0" } }
<- { "timestamp": { "seconds": 1739538634, "microseconds": 920450 },
"event": "NETDEV_VHOST_USER_DISCONNECTED",
"data": { "netdev-id": "netdev0" } }
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.
The eBPF programs that can be gotten with request-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.
-> { "execute": "query-rocker", "arguments": { "name": "sw1" } }
<- { "return": {"name": "sw1", "ports": 2, "id": 1327446905938}}
-> { "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}
]}
NOTE:
NOTE:
NOTE:
-> { "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}
},
...
]}
NOTE:
-> { "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
Return a list of supported TPM models
-> { "execute": "query-tpm-models" }
<- { "return": [ "tpm-tis", "tpm-crb", "tpm-spapr" ] }
An enumeration of TPM types
Return a list of supported TPM types
Information about the TPM passthrough type
Information about the TPM emulator type
A union referencing different TPM backend types' configuration options
Information about the TPM
Return information about the TPM device
-> { "execute": "query-tpm" }
<- { "return":
[
{ "model": "tpm-tis",
"options":
{ "type": "passthrough",
"data":
{ "cancel-path": "/sys/class/misc/tpm0/device/cancel",
"path": "/dev/tpm0"
}
},
"id": "tpm0"
}
]
}
-> { "execute": "set_password", "arguments": { "protocol": "vnc",
"password": "secret" } }
<- { "return": {} }
when to expire the password.
NOTE:
-> { "execute": "expire_password", "arguments": { "protocol": "vnc",
"time": "+60" } }
<- { "return": {} }
Capture the contents of a screen and write it to a file.
-> { "execute": "screendump",
"arguments": { "filename": "/tmp/image" } }
<- { "return": {} }
The basic information for SPICE network connection
Information about a SPICE server
Information about a SPICE client channel.
An enumeration of Spice mouse states.
Information about the SPICE session.
the current authentication type used by the server
Returns information about the current SPICE server
-> { "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
},
...
]
}
}
Emitted when a SPICE client establishes a connection
<- { "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"}
}}
Emitted after initial handshake and authentication takes place (if any) and the SPICE channel is up and running
<- { "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}
}}
Emitted when the SPICE connection is closed
<- { "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"}
}}
Emitted when SPICE migration has completed
<- { "timestamp": {"seconds": 1290688046, "microseconds": 417172},
"event": "SPICE_MIGRATE_COMPLETED" }
The basic information for vnc network connection
The network connection information for server
Information about a connected VNC client.
Information about the VNC session.
the current authentication type used by the server
vnc primary authentication method.
vnc sub authentication method with vencrypt.
The network connection information for server
Information about a vnc server
Returns information about the current VNC server
-> { "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
}
]
}
}
Returns a list of vnc servers. The list can be empty.
Change the VNC server password.
NOTE:
Emitted when a VNC client establishes a connection
NOTE:
<- { "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 } }
Emitted after authentication takes place (if any) and the VNC session is made active
<- { "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 } }
Emitted when the connection is closed
<- { "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 } }
-> { "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
}
]
}
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.
-> { "execute": "send-key",
"arguments": { "keys": [ { "type": "qcode", "data": "ctrl" },
{ "type": "qcode", "data": "alt" },
{ "type": "qcode", "data": "delete" } ] } }
<- { "return": {} }
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.
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": {} }
-> { "execute": "display-reload",
"arguments": { "type": "vnc", "tls-certs": true } }
<- { "return": {} }
-> { "execute": "display-update",
"arguments": { "type": "vnc", "addresses":
[ { "type": "inet", "host": "0.0.0.0",
"port": "5901" } ] } }
<- { "return": {} }
-> { "execute": "client_migrate_info",
"arguments": { "protocol": "spice",
"hostname": "virt42.lab.kraxel.org",
"port": 1234 } }
<- { "return": {} }
-> { "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
}
}
}
-> { "execute": "migrate-set-capabilities" , "arguments":
{ "capabilities": [ { "capability": "xbzrle", "state": true } ] } }
<- { "return": {} }
-> { "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"}
]}
The migrate command stops the VM and saves state to the URI. After quitting QEMU, the user resumes by running QEMU -incoming.
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)
This mode allows the user to transfer a guest to a new QEMU instance on the same host with minimal guest pause time by preserving guest RAM in place. Devices and their pinned pages will also be preserved in a future QEMU release.
The user starts new QEMU on the same host as old QEMU, with command-line arguments to create the same machine, plus the -incoming option for the main migration channel, like normal live migration. In addition, the user adds a second -incoming option with channel type "cpr". This CPR channel must support file descriptor transfer with SCM_RIGHTS, i.e. it must be a UNIX domain socket.
To initiate CPR, the user issues a migrate command to old QEMU, adding a second migration channel of type "cpr" in the channels argument. Old QEMU stops the VM, saves state to the migration channels, and enters the postmigrate state. Execution resumes in new QEMU.
New QEMU reads the CPR channel before opening a monitor, hence the CPR channel cannot be specified in the list of channels for a migrate-incoming command. It may only be specified on the command line.
The main channel address cannot be a file type, and for an inet socket, the port cannot be 0 (meaning dynamically choose a port).
Memory-backend objects must have the share=on attribute, but memory-backend-epc is not supported. The VM must be started with the '-machine aux-ram-share=on' option.
When using -incoming defer, you must issue the migrate command to old QEMU before issuing any monitor commands to new QEMU. However, new QEMU does not open and read the migration stream until you issue the migrate incoming command.
(since 10.0)
migration target's hostname for validating the server's x509 certificate identity. If empty, QEMU will use the hostname from the migration URI, if any. A non-empty value is required when using x509 based TLS credentials and the migration URI does not include a hostname, such as fd: or exec: based migration. (Since 2.7)
Note: empty value works only since 2.9.
migration target's hostname for validating the server's x509 certificate identity. If empty, QEMU will use the hostname from the migration URI, if any. A non-empty value is required when using x509 based TLS credentials and the migration URI does not include a hostname, such as fd: or exec: based migration. (Since 2.7)
Note: empty value works only since 2.9.
-> { "execute": "migrate-set-parameters" ,
"arguments": { "multifd-channels": 5 } }
<- { "return": {} }
ID of the 'tls-creds' object that provides credentials for establishing a TLS connection over the migration data channel. On the outgoing side of the migration, the credentials must be for a 'client' endpoint, while for the incoming side the credentials must be for a 'server' endpoint. An empty string means that QEMU will use plain text mode for migration, rather than TLS. (Since 2.7)
Note: 2.8 omits empty tls-creds instead.
migration target's hostname for validating the server's x509 certificate identity. If empty, QEMU will use the hostname from the migration URI, if any. (Since 2.7)
Note: 2.8 omits empty tls-hostname instead.
-> { "execute": "query-migrate-parameters" }
<- { "return": {
"multifd-channels": 2,
"cpu-throttle-increment": 10,
"cpu-throttle-initial": 20,
"max-bandwidth": 33554432,
"downtime-limit": 300
}
}
<- {"timestamp": {"seconds": 1432121972, "microseconds": 744001},
"event": "MIGRATION",
"data": {"status": "completed"} }
<- { "timestamp": {"seconds": 1449669631, "microseconds": 239225},
"event": "MIGRATION_PASS", "data": {"pass": 2} }
<- { "timestamp": {"seconds": 2032141960, "microseconds": 417172},
"event": "COLO_EXIT", "data": {"mode": "primary", "reason": "request" } }
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.
NOTE:
-> { "execute": "migrate-continue" , "arguments":
{ "state": "pre-switchover" } }
<- { "return": {} }
-> { "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": {} }
-> { "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": {} }
-> { "execute": "xen-save-devices-state",
"arguments": { "filename": "/tmp/save" } }
<- { "return": {} }
-> { "execute": "xen-set-global-dirty-log",
"arguments": { "enable": true } }
<- { "return": {} }
-> { "execute": "xen-load-devices-state",
"arguments": { "filename": "/tmp/resume" } }
<- { "return": {} }
Enable or disable replication.
-> { "execute": "xen-set-replication",
"arguments": {"enable": true, "primary": false} }
<- { "return": {} }
The result format for 'query-xen-replication-status'.
Query replication status while the vm is running.
Xen uses this command to notify replication to trigger a checkpoint.
The result format for 'query-colo-status'.
Query COLO status while the vm is running.
-> { "execute": "query-colo-status" }
<- { "return": { "mode": "primary", "last-mode": "none", "reason": "request" } }
-> { "execute": "migrate-recover",
"arguments": { "uri": "tcp:192.168.1.200:12345" } }
<- { "return": {} }
<- { "event": "UNPLUG_PRIMARY",
"data": { "device-id": "hostdev0" },
"timestamp": { "seconds": 1265044230, "microseconds": 450486 } }
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:
-> {"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": {} }
<- {"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"}
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.
-> {"execute": "set-vcpu-dirty-limit"}
"arguments": { "dirty-rate": 200,
"cpu-index": 1 } }
<- { "return": {} }
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".
-> {"execute": "cancel-vcpu-dirty-limit"},
"arguments": { "cpu-index": 1 } }
<- { "return": {} }
-> {"execute": "query-vcpu-dirty-limit"}
<- {"return": [
{ "limit-rate": 60, "current-rate": 3, "cpu-index": 0},
{ "limit-rate": 60, "current-rate": 3, "cpu-index": 1}]}
Returns information of migration threads
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"}]}
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"}]}
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"}]}
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:
-> { "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": {} }
-> { "execute": "trace-event-get-state",
"arguments": { "name": "qemu_memalign" } }
<- { "return": [ { "name": "qemu_memalign", "state": "disabled", "vcpu": false } ] }
-> { "execute": "trace-event-set-state",
"arguments": { "name": "qemu_memalign", "enable": true } }
<- { "return": {} }
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.
-> { "execute": "qmp_capabilities",
"arguments": { "enable": [ "oob" ] } }
<- { "return": {} }
NOTE:
NOTE:
-> { "execute": "query-version" }
<- {
"return":{
"qemu":{
"major":0,
"minor":11,
"micro":5
},
"package":""
}
}
-> { "execute": "query-commands" }
<- {
"return":[
{
"name":"query-balloon"
},
{
"name":"system_powerdown"
},
...
]
}
This example has been shortened as the real response is too long.
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:
Values of this type are JSON string on the wire.
Values of this type are JSON array on the wire.
Values of this type are JSON object on the wire.
On the wire, this can be any of the members.
the type of the property. This will typically come in one of four forms:
-> { "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>" } ] }
The path within the object model. There are two forms of supported paths--absolute and partial paths.
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.
-> { "execute": "qom-get",
"arguments": { "path": "/machine/unattached/device[0]",
"property": "hotplugged" } }
<- { "return": false }
-> { "execute": "qom-get",
"arguments": { "path": "unattached/sysbus",
"property": "type" } }
<- { "return": "System" }
-> { "execute": "qom-set",
"arguments": { "path": "/machine",
"property": "graphics",
"value": false } }
<- { "return": {} }
NOTE:
Properties for can-host-socketcan objects.
Properties for cryptodev-vhost-user 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.
Properties for input-linux objects.
The aio-max-batch option is available since 6.1.
NOTE:
Properties for memory-backend-memfd objects.
Properties for memory-backend-shm objects.
This memory backend supports only shared memory, which is the default.
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
Properties for pr-manager-helper objects.
Properties for rng-random objects.
More usage information is also available in the QEMU source tree under docs/amd-memory-encryption.
-> { "execute": "object-add",
"arguments": { "qom-type": "rng-random", "id": "rng1",
"filename": "/dev/hwrng" } }
<- { "return": {} }
NOTE:
-> { "execute": "device_add",
"arguments": { "driver": "e1000", "id": "net1",
"bus": "pci.0",
"mac": "52:54:00:12:34:56" } }
<- { "return": {} }
NOTE:
-> { "execute": "device_del",
"arguments": { "id": "/machine/peripheral-anon/device[0]" } }
<- { "return": {} }
<- { "event": "DEVICE_DELETED",
"data": { "device": "virtio-net-pci-0",
"path": "/machine/peripheral/virtio-net-pci-0" },
"timestamp": { "seconds": 1265044230, "microseconds": 450486 } }
<- { "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 capacity change. Currently only vhost-user-blk device supports this.
NOTE:
-> { "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
}
]
}
-> { "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"
},
...
}
NOTE:
-> { "execute": "query-uuid" }
<- { "return": { "UUID": "550e8400-e29b-41d4-a716-446655440000" } }
NOTE:
NOTE:
NOTE:
For more information about HmatLBMemoryHierarchy, see chapter 5.2.27.4: Table 5-146: Field "Flags" of ACPI 6.3 spec.
For more information about HmatLBDataType, see chapter 5.2.27.4: Table 5-146: Field "Data Type" of ACPI 6.3 spec.
For more information about NumaHmatLBOptions, see chapter 5.2.27.4: Table 5-146 of ACPI 6.3 spec.
For more information of HmatCacheAssociativity, see chapter 5.2.27.5: Table 5-147 of ACPI 6.3 spec.
For more information of HmatCacheWritePolicy, see chapter 5.2.27.5: Table 5-147: Field "Cache Attributes" of ACPI 6.3 spec.
For more information of NumaHmatCacheOptions, see chapter 5.2.27.5: Table 5-147: Field "Cache Attributes" of ACPI 6.3 spec.
CAUTION:
-> { "execute": "memsave",
"arguments": { "val": 10,
"size": 100,
"filename": "/tmp/virtual-mem-dump" } }
<- { "return": {} }
CAUTION:
-> { "execute": "pmemsave",
"arguments": { "val": 10,
"size": 100,
"filename": "/tmp/physical-mem-dump" } }
<- { "return": {} }
-> { "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"
}
]
}
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)
NOTE:
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 }
}
]}
the target logical size of the VM in bytes. We can deduce the size of the balloon using this formula:
From it we have: balloon_size = vm_ram_size - value
NOTE:
-> { "execute": "balloon", "arguments": { "value": 536870912 } }
<- { "return": {} }
With a 2.5GiB guest this command inflated the ballon to 3GiB.
NOTE:
<- { "event": "BALLOON_CHANGE",
"data": { "actual": 944766976 },
"timestamp": { "seconds": 1267020223, "microseconds": 435656 } }
-> { "execute": "query-hv-balloon-status-report" }
<- { "return": {
"committed": 816640000,
"available": 3333054464
}
}
NOTE:
<- { "event": "HV_BALLOON_STATUS_REPORT",
"data": { "committed": 816640000, "available": 3333054464 },
"timestamp": { "seconds": 1600295492, "microseconds": 661044 } }
-> { "execute": "query-memory-size-summary" }
<- { "return": { "base-memory": 4294967296, "plugged-memory": 0 } }
-> { "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"
} ] }
NOTE:
<- { "event": "MEMORY_DEVICE_SIZE_CHANGE",
"data": { "id": "vm0", "size": 1073741824,
"qom-path": "/machine/unattached/device[2]" },
"timestamp": { "seconds": 1588168529, "microseconds": 201316 } }
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.
Query interrupt statistics
Query TCG compiler statistics
Query NUMA topology information
Query TCG opcode counters
Query system ramblock information
Query information on the registered ROMS
Query information on the USB devices
Query information on interrupt controller devices
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.
NOTE:
The result of a CPU model baseline.
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.
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.
NOTE:
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.
NOTE:
The result of a cpu model expansion.
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".
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.
Return a list of supported virtual CPU definitions
An enumeration of CPU polarization that can be assumed by a virtual S390 CPU
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.
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.
<- { "event": "CPU_POLARIZATION_CHANGE",
"data": { "polarization": "horizontal" },
"timestamp": { "seconds": 1401385907, "microseconds": 422329 } }
The result of a CPU polarization query.
-> { "execute": "query-replay" }
<- { "return": { "mode": "play", "filename": "log.rr", "icount": 220414 } }
Currently implemented yank instances:
-> { "execute": "yank",
"arguments": {
"instances": [
{ "type": "block-node",
"node-name": "nbd0" }
] } }
<- { "return": {} }
-> { "execute": "query-yank" }
<- { "return": [
{ "type": "block-node",
"node-name": "nbd0" }
] }
If the FD associated with fdname is not a socket, the command will fail and the FD will be closed.
-> { "execute": "add_client", "arguments": { "protocol": "vnc",
"fdname": "myclient" } }
<- { "return": {} }
NOTE:
-> { "execute": "query-iothreads" }
<- { "return": [
{
"id":"iothread0",
"thread-id":3134
},
{
"id":"iothread1",
"thread-id":3135
}
]
}
NOTE:
In the "suspended" state, it will completely stop the VM and cause a transition to the "paused" state. (Since 9.0)
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).
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
NOTE:
The 'closefd' command can be used to explicitly close the file descriptor when it is no longer needed.
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)
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": {} }
NOTE:
NOTE:
-> { "execute": "add-fd", "arguments": { "fdset-id": 1 } }
<- { "return": { "fdset-id": 1, "fd": 3 } }
NOTE:
NOTE:
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
}
]
}
-> { "execute": "query-command-line-options",
"arguments": { "option": "option-rom" } }
<- { "return": [
{
"parameters": [
{
"name": "romfile",
"type": "string"
},
{
"name": "bootindex",
"type": "number"
}
],
"option": "option-rom"
}
]
}
NOTE:
<- { "event": "RTC_CHANGE",
"data": { "offset": 78 },
"timestamp": { "seconds": 1267020223, "microseconds": 435656 } }
<- { "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.
An enumeration of SEV state information used during query-sev.
An enumeration indicating the type of SEV guest being run.
Information specific to legacy SEV/SEV-ES guests.
Information specific to SEV-SNP guests.
Information about Secure Encrypted Virtualization (SEV) support
Returns information about SEV
-> { "execute": "query-sev" }
<- { "return": { "enabled": true, "api-major" : 0, "api-minor" : 0,
"build-id" : 0, "policy" : 0, "state" : "running",
"handle" : 1 } }
SEV Guest Launch measurement information
Query the SEV guest launch information.
-> { "execute": "query-sev-launch-measure" }
<- { "return": { "data": "4l8LXeNlSPUDlXPJG5966/8%YZ" } }
The struct describes capability for a Secure Encrypted Virtualization feature.
This command is used to get the SEV capabilities, and is supported on AMD X86 platforms only.
-> { "execute": "query-sev-capabilities" }
<- { "return": { "pdh": "8CCDD8DDD", "cert-chain": "888CCCDDDEE",
"cpu0-id": "2lvmGwo+...61iEinw==",
"cbitpos": 47, "reduced-phys-bits": 1}}
This command injects a secret blob into memory of SEV guest.
The struct describes attestation report for a Secure Encrypted Virtualization feature.
This command is used to get the SEV attestation report, and is supported on AMD X86 platforms only.
-> { "execute" : "query-sev-attestation-report",
"arguments": { "mnonce": "aaaaaaa" } }
<- { "return" : { "data": "aaaaaaaabbbddddd"} }
Dump guest's storage keys
-> { "execute": "dump-skeys",
"arguments": { "filename": "/tmp/skeys" } }
<- { "return": {} }
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.
This command is ARM-only. It will return a list of GICCapability objects that describe its capability bits.
-> { "execute": "query-gic-capabilities" }
<- { "return": [{ "version": 2, "emulated": true, "kernel": false },
{ "version": 3, "emulated": false, "kernel": true } ] }
Information about intel Safe Guard eXtension (SGX) support
Returns information about configured SGX capabilities of guest
-> { "execute": "query-sgx" }
<- { "return": { "sgx": true, "sgx1" : true, "sgx2" : true,
"flc": true,
"sections": [{"node": 0, "size": 67108864},
{"node": 1, "size": 29360128}]} }
Returns information about SGX capabilities of host
-> { "execute": "query-sgx-capabilities" }
<- { "return": { "sgx": true, "sgx1" : true, "sgx2" : true,
"flc": true,
"section" : [{"node": 0, "size": 67108864},
{"node": 1, "size": 29360128}]} }
An enumeration of Xen event channel port types.
Information about a Xen event channel port
Query the Xen event channels opened by the guest.
-> { "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
}
]
}
Inject a Xen event channel port (interrupt) to the guest.
10ms at 48kHz).
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.
-> { "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}
]}
<- { "event": "ACPI_DEVICE_OST",
"data": { "info": { "device": "d1", "slot": "0",
"slot-type": "DIMM", "source": 1, "status": 0 } },
"timestamp": { "seconds": 1265044230, "microseconds": 450486 } }
-> { "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.
The arguments are a StatsFilter and specify the provider and objects to return statistics about.
NOTE:
Returns a list of all realized VirtIODevices
-> { "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"
}
]
}
Poll for a comprehensive status of a given virtio device
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
}
}
Return the status of a given VirtIODevice's VirtQueue
NOTE:
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
}
}
Return information of a given vhost device's vhost_virtqueue
-> { "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
}
}
Return the information about a VirtQueue's VirtQueueElement
-> { "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
}
}
}
<- { "timestamp": { "seconds": 1713771323, "microseconds": 212268 },
"event": "VFIO_MIGRATION",
"data": {
"device-id": "vfio_dev1",
"qom-path": "/machine/peripheral/vfio_dev1",
"device-state": "stop" } }
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.
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.
The qemu efi variable store implementation (hw/uefi/) uses this to store non-volatile variables in json format on disk.
This is an existing format already supported by (at least) two other projects, specifically https://gitlab.com/kraxel/virt-firmware and https://github.com/awslabs/python-uefivars.
2025, The QEMU Project Developers
| November 4, 2025 | 10.0.6 |