qemu-storage-daemon-qmp-ref
QEMU Storage Daemon QMP Reference Manual
- Provided by: qemu-utils-hwe (Version: 1:10.2.1+ds-1ubuntu4)
- Source: qemu-hwe
- Report a bug
QEMU Storage Daemon QMP Reference Manual
This manual describes the commands and events supported by the QEMU storage daemon QMP.
For locating a particular item, please see the QSD 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:
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.
This command also clears the error status for block-jobs (stream, commit, mirror, backup).
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 is supported only for drive mirroring, where it also switches the device to write to the target path only. Note that drive mirroring includes drive-mirror, blockdev-mirror and block-commit job (only in case of "active commit", when the node being commited is used by the guest). The ability to complete is signaled with a BLOCK_JOB_READY event.
This command completes an active background block operation synchronously. The ordering of this command's return with the BLOCK_JOB_COMPLETED event is not defined. Note that if an I/O error occurs during the processing of this command: 1) the command itself will fail; 2) the error will be processed according to the rerror/werror arguments that were specified when starting the operation.
This command will refuse to operate on any job that has not yet reached its terminal state, CONCLUDED. For jobs that make use of the 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.
The command is applicable only to jobs which have auto-finalize option and only when this option is set to false.
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 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 job-cancel or 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 job-cancel or 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.
Pause an active background block operation.
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.
Resume an active background block operation.
This command returns immediately after resuming a paused job. Resuming an already running job is an error.
This command also clears the error status of the job.
Manually trigger completion of an active job in the READY or STANDBY state. Completing the job in any other state is an error.
This is supported only for drive mirroring, where it also switches the device to write to the target path only. Note that drive mirroring includes drive-mirror, blockdev-mirror and block-commit job (only in case of "active commit", when the node being commited is used by the guest). The ability to complete is signaled with a BLOCK_JOB_READY event.
This command completes an active background block operation synchronously. The ordering of this command's return with the BLOCK_JOB_COMPLETED event is not defined. Note that if an I/O error occurs during the processing of this command: 1) the command itself will fail; 2) the error will be processed according to the rerror/werror arguments that were specified when starting the operation.
Deletes a job that is in the CONCLUDED state. This command only needs to be run explicitly for jobs that don't have automatic dismiss enabled. In turn, automatic dismiss may be enabled only for jobs that have auto-dismiss option, which are drive-backup, blockdev-backup, drive-mirror, blockdev-mirror, block-commit and block-stream. auto-dismiss is enabled by default for these jobs.
This command will refuse to operate on any job that has not yet reached its terminal state, CONCLUDED. For jobs that make use of the BLOCK_JOB_READY event, job-cancel, block-job-cancel or job-complete will still need to be used as appropriate.
Instructs all jobs in a transaction (or a single job if it is not part of any transaction) to finalize any graph changes and do any necessary cleanup. This command requires that all involved jobs are in the PENDING state.
For jobs in a transaction, instructing one job to finalize will force ALL jobs in the transaction to finalize, so it is only necessary to instruct a single member job to finalize.
The command is applicable only to jobs which have auto-finalize option and only when this option is set to false.
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
}
}
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 } }
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": "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.
While every attempt is made to send the QMP response before terminating, this is not guaranteed. When using this interface, a premature EOF would not be unexpected.
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.
an array where each element describes an entity in the ABI: command, event, type, ...
The order of the various elements 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:
Since 10.1
Since 10.1
-> { "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" }
Since 10.1
-> { "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.
Properties common to objects that handle IGVM files.
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": {} }
2025, The QEMU Project Developers