QEMU-STORAGE-DAEMON-QMP-REF(7) | QEMU | QEMU-STORAGE-DAEMON-QMP-REF(7) |
qemu-storage-daemon-qmp-ref - QEMU Storage Daemon QMP Reference Manual
An enumeration of the I/O operation types
2.1
An enumeration of three options: on, off, and auto
2.2
An enumeration of three values: on, off, and split
2.6
This is a string value or the explicit lack of a string (null pointer in C). Intended for cases when 'optional absent' already has a different meaning.
2.10
An enumeration of options for specifying a PCI BAR
2.12
An enumeration of PCIe link speeds in units of GT/s
4.0
An enumeration of PCIe link width
4.0
Host memory policy types
2.1
Indicates whether a netfilter is attached to a netdev's transmit queue or receive queue or both.
2.5
Key combinations to toggle input-linux between host and guest.
4.0
6.2
The network address family
2.1
Captures a socket address or address range in the Internet namespace.
1.3
Captures a socket address in the local ("Unix socket") namespace.
1.3
Captures a socket address in the vsock namespace.
NOTE:
2.8
A file descriptor name or number.
1.2
1.3
1.3
2.8
1.3
Captures the address of a socket, which could also be a named file descriptor
1.3
Available SocketAddress types
2.9
Captures the address of a socket, which could also be a socket file descriptor
2.9
The type of network endpoint that will be using the credentials. Most types of credential require different setup / structures depending on whether they will be used in a server versus a client.
2.5
The data format that the secret is provided in
2.6
The supported algorithms for computing content digests
2.6
The supported algorithms for content encryption ciphers
2.6
The supported modes for content encryption ciphers
2.6
The supported algorithms for generating initialization vectors for full disk encryption. The 'plain' generator should not be used for disks with sector numbers larger than 2^32, except where compatibility with pre-existing Linux dm-crypt volumes is required.
2.6
The supported full disk encryption formats
2.6
The common options that apply to all full disk encryption formats
2.6
The options that apply to QCow/QCow2 AES-CBC encryption format
2.6
The options that apply to LUKS encryption format
2.6
The options that apply to LUKS encryption format initialization
2.6
The options that are available for all encryption formats when opening an existing volume
2.6
The options that are available for all encryption formats when initializing a new volume
2.6
The common information that applies to all full disk encryption formats
2.7
Information about the LUKS block encryption key slot options
2.7
Information about the LUKS block encryption options
2.7
Information about the block encryption options
2.7
Defines state of keyslots that are affected by the update
5.1
This struct defines the update parameters that activate/de-activate set of keyslots
For keyslot deactivation, this parameter specifies the exact keyslot to deactivate
5.1
The options that are available for all encryption formats when amending encryption settings
5.1
Properties for objects of classes derived from secret-common.
2.6
Properties for secret objects.
Either data or file must be provided, but not both.
2.6
Properties for secret_keyring objects.
5.1
CONFIG_SECRET_KEYRING
Properties for objects of classes derived from tls-creds.
2.5
Properties for tls-creds-anon objects.
2.5
Properties for tls-creds-psk objects.
3.0
Properties for tls-creds-x509 objects.
2.5
The supported algorithms for asymmetric encryption ciphers
7.1
The type of asymmetric keys.
7.1
The padding algorithm for RSA.
7.1
Specific parameters for RSA algorithm.
7.1
The options that are available for all asymmetric key algorithms when creating a new QCryptoAkCipher.
7.1
Type of a background job.
1.7
Indicates the present state of a given job in its lifetime.
2.12
Represents command verbs that can be applied to a job.
2.12
Emitted when a job transitions to a different status.
3.0
Pause an active job.
This command returns immediately after marking the active job for pausing. Pausing an already paused job is an error.
The job will pause as soon as possible, which means transitioning into the PAUSED state if it was RUNNING, or into STANDBY if it was READY. The corresponding JOB_STATUS_CHANGE event will be emitted.
Cancelling a paused job automatically resumes it.
3.0
Resume a paused job.
This command returns immediately after resuming a paused job. Resuming an already running job is an error.
3.0
Instruct an active background job to cancel at the next opportunity. This command returns immediately after marking the active job for cancellation.
The job will cancel as soon as possible and then emit a JOB_STATUS_CHANGE event. Usually, the status will change to ABORTING, but it is possible that a job successfully completes (e.g. because it was almost done and there was no opportunity to cancel earlier than completing the job) and transitions to PENDING instead.
3.0
Manually trigger completion of an active job in the READY state.
3.0
Deletes a job that is in the CONCLUDED state. This command only needs to be run explicitly for jobs that don't have automatic dismiss enabled.
This command will refuse to operate on any job that has not yet reached its terminal state, JOB_STATUS_CONCLUDED. For jobs that make use of JOB_READY event, job-cancel or job-complete will still need to be used as appropriate.
3.0
Instructs all jobs in a transaction (or a single job if it is not part of any transaction) to finalize any graph changes and do any necessary cleanup. This command requires that all involved jobs are in the PENDING state.
For jobs in a transaction, instructing one job to finalize will force ALL jobs in the transaction to finalize, so it is only necessary to instruct a single member job to finalize.
3.0
Information about a job.
The value is a human-readable error message to describe the reason for the job failure. It should not be parsed by applications.
3.0
Return information about jobs.
a list with a JobInfo for each active job
3.0
1.3
2.10
2.10
1.7
1.7
Information about a VMDK extent file
8.0
6.1
8.0
1.7
1.7
6.1
2.7
6.1
8.0
A discriminated record of image format specific information structures.
1.7
Information about a QEMU image file
8.0
Information about a QEMU image file, and potentially its backing image
1.3
Information about all nodes in the block graph starting at some node, annotated with information about that node in relation to its parent.
8.0
Information about all nodes in a block (sub)graph in the form of BlockNodeInfo data. The base BlockNodeInfo struct contains the information for the (sub)graph's root node.
8.0
Information about a QEMU image file check
1.4
Mapping information from a virtual block range to a host file range
2.6
Cache mode information for a block device
2.3
Information about the backing device for a block device.
0.14
An enumeration of block device I/O status.
1.0
Block dirty bitmap information.
1.3
An enumeration of flags that a bitmap can report to the user.
4.0
Qcow2 bitmap information.
4.0
Block latency histogram.
5| * 4| * 3| * * 2| * * * 1| * * * * +------------------ 10 50 100
4.0
Block device information. This structure describes a virtual device and the backing device associated with it.
0.14
Image file size calculation information. This structure describes the size requirements for creating a new image file.
The size requirements depend on the new image file format. File size always equals virtual disk size for the 'raw' format, even for sparse POSIX files. Compact formats such as 'qcow2' represent unallocated and zero regions efficiently so file size may be smaller than virtual disk size.
The values are upper bounds that are guaranteed to fit the new image file. Subsequent modification, such as internal snapshot or further bitmap creation, may require additional space and is not covered here.
2.10
Get a list of BlockInfo for all virtual block devices.
a list of BlockInfo describing each virtual block device. Filter nodes that were created implicitly are skipped over.
0.14
-> { "execute": "query-block" } <- { "return":[ { "io-status": "ok", "device":"ide0-hd0", "locked":false, "removable":false, "inserted":{ "ro":false, "drv":"qcow2", "encrypted":false, "file":"disks/test.qcow2", "backing_file_depth":1, "bps":1000000, "bps_rd":0, "bps_wr":0, "iops":1000000, "iops_rd":0, "iops_wr":0, "bps_max": 8000000, "bps_rd_max": 0, "bps_wr_max": 0, "iops_max": 0, "iops_rd_max": 0, "iops_wr_max": 0, "iops_size": 0, "detect_zeroes": "on", "write_threshold": 0, "image":{ "filename":"disks/test.qcow2", "format":"qcow2", "virtual-size":2048000, "backing_file":"base.qcow2", "full-backing-filename":"disks/base.qcow2", "backing-filename-format":"qcow2", "snapshots":[ { "id": "1", "name": "snapshot1", "vm-state-size": 0, "date-sec": 10000200, "date-nsec": 12, "vm-clock-sec": 206, "vm-clock-nsec": 30 } ], "backing-image":{ "filename":"disks/base.qcow2", "format":"qcow2", "virtual-size":2048000 } } }, "qdev": "ide_disk", "type":"unknown" }, { "io-status": "ok", "device":"ide1-cd0", "locked":false, "removable":true, "qdev": "/machine/unattached/device[23]", "tray_open": false, "type":"unknown" }, { "device":"floppy0", "locked":false, "removable":true, "qdev": "/machine/unattached/device[20]", "type":"unknown" }, { "device":"sd0", "locked":false, "removable":true, "type":"unknown" } ] }
Statistics of a block device during a given interval of time.
2.5
Statistics of a virtual block device or a block backing device.
0.14
File driver statistics
4.2
NVMe driver statistics
5.2
Block driver specific statistics
4.2
Statistics of a virtual block device or a block backing device.
0.14
Query the BlockStats for all virtual block devices.
A list of BlockStats for each virtual block devices.
0.14
-> { "execute": "query-blockstats" } <- { "return":[ { "device":"ide0-hd0", "parent":{ "stats":{ "wr_highest_offset":3686448128, "wr_bytes":9786368, "wr_operations":751, "rd_bytes":122567168, "rd_operations":36772 "wr_total_times_ns":313253456 "rd_total_times_ns":3465673657 "flush_total_times_ns":49653 "flush_operations":61, "rd_merged":0, "wr_merged":0, "idle_time_ns":2953431879, "account_invalid":true, "account_failed":false } }, "stats":{ "wr_highest_offset":2821110784, "wr_bytes":9786368, "wr_operations":692, "rd_bytes":122739200, "rd_operations":36604 "flush_operations":51, "wr_total_times_ns":313253456 "rd_total_times_ns":3465673657 "flush_total_times_ns":49653, "rd_merged":0, "wr_merged":0, "idle_time_ns":2953431879, "account_invalid":true, "account_failed":false }, "qdev": "/machine/unattached/device[23]" }, { "device":"ide1-cd0", "stats":{ "wr_highest_offset":0, "wr_bytes":0, "wr_operations":0, "rd_bytes":0, "rd_operations":0 "flush_operations":0, "wr_total_times_ns":0 "rd_total_times_ns":0 "flush_total_times_ns":0, "rd_merged":0, "wr_merged":0, "account_invalid":false, "account_failed":false }, "qdev": "/machine/unattached/device[24]" }, { "device":"floppy0", "stats":{ "wr_highest_offset":0, "wr_bytes":0, "wr_operations":0, "rd_bytes":0, "rd_operations":0 "flush_operations":0, "wr_total_times_ns":0 "rd_total_times_ns":0 "flush_total_times_ns":0, "rd_merged":0, "wr_merged":0, "account_invalid":false, "account_failed":false }, "qdev": "/machine/unattached/device[16]" }, { "device":"sd0", "stats":{ "wr_highest_offset":0, "wr_bytes":0, "wr_operations":0, "rd_bytes":0, "rd_operations":0 "flush_operations":0, "wr_total_times_ns":0 "rd_total_times_ns":0 "flush_total_times_ns":0, "rd_merged":0, "wr_merged":0, "account_invalid":false, "account_failed":false } } ] }
An enumeration of possible behaviors for errors on I/O operations. The exact meaning depends on whether the I/O was initiated by a guest or by a block job
1.3
An enumeration of possible behaviors for the initial synchronization phase of storage mirroring.
1.3
An enumeration of possible behaviors for the synchronization of a bitmap when used for data copy operations.
4.2
An enumeration whose values tell the mirror block job when to trigger writes to the target.
3.0
Information specific to mirror block jobs.
8.2
Information about a long-running block device operation.
1.1
Return information about long-running block device operations.
a list of BlockJobInfo for each active block job
1.1
Resize a block image while a guest is running.
Either device or node-name must be set but not both.
0.14
-> { "execute": "block_resize", "arguments": { "device": "scratch", "size": 1073741824 } } <- { "return": {} }
An enumeration that tells QEMU how to set the backing file path in a new image file.
1.1
Either device or node-name must be set but not both.
2.5
Optional parameters for backup. These parameters don't affect functionality, but may significantly affect performance.
6.0
NOTE:
4.2
1.6
2.3
Takes a synchronous snapshot of a block device.
0.14
-> { "execute": "blockdev-snapshot-sync", "arguments": { "device": "ide-hd0", "snapshot-file": "/some/place/my-image", "format": "qcow2" } } <- { "return": {} }
Takes a snapshot of a block device.
Take a snapshot, by installing 'node' as the backing image of 'overlay'. Additionally, if 'node' is associated with a block device, the block device changes to using 'overlay' as its new active image.
2.5
-> { "execute": "blockdev-add", "arguments": { "driver": "qcow2", "node-name": "node1534", "file": { "driver": "file", "filename": "hd1.qcow2" }, "backing": null } } <- { "return": {} } -> { "execute": "blockdev-snapshot", "arguments": { "node": "ide-hd0", "overlay": "node1534" } } <- { "return": {} }
Change the backing file in the image file metadata. This does not cause QEMU to reopen the image file to reparse the backing filename (it may, however, perform a reopen to change permissions from r/o -> r/w -> r/o, if needed). The new backing file string is written into the image file metadata, and the QEMU internal strings are updated.
2.1
Live commit of data from overlay image nodes into backing nodes - i.e., writes data between 'top' and 'base' into 'base'.
If top == base, that is an error. If top has no overlays on top of it, or if it is in use by a writer, the job will not be completed by itself. The user needs to complete the job with the block-job-complete command after getting the ready event. (Since 2.0)
If the base image is smaller than top, then the base image will be resized to be the same size as top. If top is smaller than the base image, the base will not be truncated. If you want the base image size to match the size of the smaller top, you can safely truncate it yourself once the commit operation successfully completes.
This filename is not validated. If a pathname string is such that it cannot be resolved by QEMU, that means that subsequent QMP or HMP commands must use node-names for the image in question, as filename lookup methods will fail.
If not specified, QEMU will automatically determine the backing file string to use, or error out if there is no obvious choice. Care should be taken when specifying the string, to specify a valid filename or protocol. (Since 2.1)
1.3
-> { "execute": "block-commit", "arguments": { "device": "virtio0", "top": "/tmp/snap1.qcow2" } } <- { "return": {} }
Start a point-in-time copy of a block device to a new destination. The status of ongoing drive-backup operations can be checked with query-block-jobs where the BlockJobInfo.type field has the value 'backup'. The operation can be stopped before it has completed using the block-job-cancel command.
1.6
-> { "execute": "drive-backup", "arguments": { "device": "drive0", "sync": "full", "target": "backup.img" } } <- { "return": {} }
Start a point-in-time copy of a block device to a new destination. The status of ongoing blockdev-backup operations can be checked with query-block-jobs where the BlockJobInfo.type field has the value 'backup'. The operation can be stopped before it has completed using the block-job-cancel command.
2.3
-> { "execute": "blockdev-backup", "arguments": { "device": "src-id", "sync": "full", "target": "tgt-id" } } <- { "return": {} }
Get the named block driver list
the list of BlockDeviceInfo
2.0
-> { "execute": "query-named-block-nodes" } <- { "return": [ { "ro":false, "drv":"qcow2", "encrypted":false, "file":"disks/test.qcow2", "node-name": "my-node", "backing_file_depth":1, "detect_zeroes":"off", "bps":1000000, "bps_rd":0, "bps_wr":0, "iops":1000000, "iops_rd":0, "iops_wr":0, "bps_max": 8000000, "bps_rd_max": 0, "bps_wr_max": 0, "iops_max": 0, "iops_rd_max": 0, "iops_wr_max": 0, "iops_size": 0, "write_threshold": 0, "image":{ "filename":"disks/test.qcow2", "format":"qcow2", "virtual-size":2048000, "backing_file":"base.qcow2", "full-backing-filename":"disks/base.qcow2", "backing-filename-format":"qcow2", "snapshots":[ { "id": "1", "name": "snapshot1", "vm-state-size": 0, "date-sec": 10000200, "date-nsec": 12, "vm-clock-sec": 206, "vm-clock-nsec": 30 } ], "backing-image":{ "filename":"disks/base.qcow2", "format":"qcow2", "virtual-size":2048000 } } } ] }
4.0
4.0
Enum of base block permissions.
4.0
Block Graph edge description for x-debug-query-block-graph.
4.0
Block Graph - list of nodes and list of edges.
4.0
Get the block graph.
4.0
Start mirroring a block device's writes to a new destination. target specifies the target of the new image. If the file exists, or if it is a device, it will be used as the new destination for writes. If it does not exist, a new file will be created. format specifies the format of the mirror image, default is to probe if mode='existing', else the format of the source.
1.3
-> { "execute": "drive-mirror", "arguments": { "device": "ide-hd0", "target": "/some/place/my-image", "sync": "full", "format": "qcow2" } } <- { "return": {} }
A set of parameters describing drive mirror setup.
1.3
2.4
2.4
4.1
4.0
Create a dirty bitmap with a name on the node, and start tracking the writes.
2.4
-> { "execute": "block-dirty-bitmap-add", "arguments": { "node": "drive0", "name": "bitmap0" } } <- { "return": {} }
Stop write tracking and remove the dirty bitmap that was created with block-dirty-bitmap-add. If the bitmap is persistent, remove it from its storage too.
2.4
-> { "execute": "block-dirty-bitmap-remove", "arguments": { "node": "drive0", "name": "bitmap0" } } <- { "return": {} }
Clear (reset) a dirty bitmap on the device, so that an incremental backup from this point in time forward will only backup clusters modified after this clear operation.
2.4
-> { "execute": "block-dirty-bitmap-clear", "arguments": { "node": "drive0", "name": "bitmap0" } } <- { "return": {} }
Enables a dirty bitmap so that it will begin tracking disk changes.
4.0
-> { "execute": "block-dirty-bitmap-enable", "arguments": { "node": "drive0", "name": "bitmap0" } } <- { "return": {} }
Disables a dirty bitmap so that it will stop tracking disk changes.
4.0
-> { "execute": "block-dirty-bitmap-disable", "arguments": { "node": "drive0", "name": "bitmap0" } } <- { "return": {} }
Merge dirty bitmaps listed in bitmaps to the target dirty bitmap. Dirty bitmaps in bitmaps will be unchanged, except if it also appears as the target bitmap. Any bits already set in target will still be set after the merge, i.e., this operation does not clear the target. On error, target is unchanged.
The resulting bitmap will count as dirty any clusters that were dirty in any of the source bitmaps. This can be used to achieve backup checkpoints, or in simpler usages, to copy bitmaps.
4.0
-> { "execute": "block-dirty-bitmap-merge", "arguments": { "node": "drive0", "target": "bitmap0", "bitmaps": ["bitmap1"] } } <- { "return": {} }
SHA256 hash of dirty bitmap data
2.10
Get bitmap SHA256.
BlockDirtyBitmapSha256
2.10
Start mirroring a block device's writes to a new destination.
2.6
-> { "execute": "blockdev-mirror", "arguments": { "device": "ide-hd0", "target": "target0", "sync": "full" } } <- { "return": {} }
A set of parameters describing block throttling.
1.1
Limit parameters for throttling. Since some limit combinations are illegal, limits should always be set in one transaction. All fields are optional. When setting limits, if a field is missing the current value is not changed.
2.11
Properties for throttle-group objects.
2.11
Copy data from a backing file into a block device.
The block streaming operation is performed in the background until the entire backing file has been copied. This command returns immediately once streaming has started. The status of ongoing block streaming operations can be checked with query-block-jobs. The operation can be stopped before it has completed using the block-job-cancel command.
The node that receives the data is called the top image, can be located in any part of the chain (but always above the base image; see below) and can be specified using its device or node name. Earlier qemu versions only allowed 'device' to name the top level node; presence of the 'base-node' parameter during introspection can be used as a witness of the enhanced semantics of 'device'.
If a base file is specified then sectors are not copied from that base file and its backing chain. This can be used to stream a subset of the backing file chain instead of flattening the entire image. When streaming completes the image file will have the base file as its backing file, unless that node was changed while the job was running. In that case, base's parent's backing (or filtered, whichever exists) child (i.e., base at the beginning of the job) will be the new backing file.
On successful completion the image file is updated to drop the backing file and the BLOCK_JOB_COMPLETED event is emitted.
In case device is a filter node, block-stream modifies the first non-filter overlay node below it to point to the new backing node instead of modifying device itself.
If a pathname string is such that it cannot be resolved by QEMU, that means that subsequent QMP or HMP commands must use node-names for the image in question, as filename lookup methods will fail.
If not specified, QEMU will automatically determine the backing file string to use, or error out if there is no obvious choice. Care should be taken when specifying the string, to specify a valid filename or protocol. (Since 2.1)
1.1
-> { "execute": "block-stream", "arguments": { "device": "virtio0", "base": "/tmp/master.qcow2" } } <- { "return": {} }
Set maximum speed for a background block operation.
This command can only be issued when there is an active block job.
Throttling can be disabled by setting the speed to 0.
1.1
Stop an active background block operation.
This command returns immediately after marking the active background block operation for cancellation. It is an error to call this command if no operation is in progress.
The operation will cancel as soon as possible and then emit the BLOCK_JOB_CANCELLED event. Before that happens the job is still visible when enumerated using query-block-jobs.
Note that if you issue 'block-job-cancel' after 'drive-mirror' has indicated (via the event BLOCK_JOB_READY) that the source and destination are synchronized, then the event triggered by this command changes to BLOCK_JOB_COMPLETED, to indicate that the mirroring has ended and the destination now has a point-in-time copy tied to the time of the cancellation.
For streaming, the image file retains its backing file unless the streaming operation happens to complete just as it is being cancelled. A new streaming operation can be started at a later time to finish copying all data from the backing file.
1.1
Pause an active background block operation.
This command returns immediately after marking the active background block operation for pausing. It is an error to call this command if no operation is in progress or if the job is already paused.
The operation will pause as soon as possible. No event is emitted when the operation is actually paused. Cancelling a paused job automatically resumes it.
1.3
Resume an active background block operation.
This command returns immediately after resuming a paused background block operation. It is an error to call this command if no operation is in progress or if the job is not paused.
This command also clears the error status of the job.
1.3
Manually trigger completion of an active background block operation. This is supported for drive mirroring, where it also switches the device to write to the target path only. The ability to complete is signaled with a BLOCK_JOB_READY event.
This command completes an active background block operation synchronously. The ordering of this command's return with the BLOCK_JOB_COMPLETED event is not defined. Note that if an I/O error occurs during the processing of this command: 1) the command itself will fail; 2) the error will be processed according to the rerror/werror arguments that were specified when starting the operation.
A cancelled or paused job cannot be completed.
1.3
For jobs that have already concluded, remove them from the block-job-query list. This command only needs to be run for jobs which were started with QEMU 2.12+ job lifetime management semantics.
This command will refuse to operate on any job that has not yet reached its terminal state, JOB_STATUS_CONCLUDED. For jobs that make use of the BLOCK_JOB_READY event, block-job-cancel or block-job-complete will still need to be used as appropriate.
2.12
Once a job that has manual=true reaches the pending state, it can be instructed to finalize any graph changes and do any necessary cleanup via this command. For jobs in a transaction, instructing one job to finalize will force ALL jobs in the transaction to finalize, so it is only necessary to instruct a single member job to finalize.
2.12
8.2
Block job options that can be changed after job creation.
8.2
Change the block job's options.
8.2
Determines how to handle discard requests.
2.9
Describes the operation mode for the automatic conversion of plain zero writes by the OS to driver specific optimized zero write commands.
2.1
Selects the AIO backend to handle I/O requests
2.9
Includes cache-related options for block devices
2.9
Drivers that are supported in block device operations.
2.9
Driver specific block device options for the file backend.
2.9
Driver specific block device options for the null backend.
2.9
Driver specific block device options for the NVMe backend.
Note that the PCI device must have been unbound from any host kernel driver before instructing QEMU to add the blockdev.
2.12
Driver specific block device options for the vvfat protocol.
2.9
Driver specific block device options for image format that have no option besides their data source.
2.9
Driver specific block device options for LUKS.
2.9
Driver specific block device options for image format that have no option besides their data source and an optional backing file.
2.9
General overlap check modes.
2.9
Structure of flags for each metadata structure. Setting a field to 'true' makes QEMU guard that Qcow2 format structure against unintended overwriting. See Qcow2 format specification for detailed information on these structures. The default value is chosen according to the template given.
2.9
Specifies which metadata structures should be guarded against unintended overwriting.
2.9
2.10
2.10
Driver specific block device options for qcow.
2.10
2.10
2.10
Filter driver intended to be inserted between format and protocol node and do preallocation in protocol node on write.
6.0
Driver specific block device options for qcow2.
2.9
2.12
2.12
2.12
2.12
2.9
Trigger events supported by blkdebug.
2.9
Kinds of I/O that blkdebug can inject errors in.
4.1
Describes a single error injection for blkdebug.
2.9
Describes a single state-change event for blkdebug.
2.9
Driver specific block device options for blkdebug.
2.9
Driver specific block device options for blklogwrites.
3.0
Driver specific block device options for blkverify.
2.9
Driver specific block device options for blkreplay.
4.2
An enumeration of quorum read patterns.
2.9
Driver specific block device options for Quorum
2.9
Driver specific block device options for Gluster
2.9
Driver specific block device options for the io_uring backend.
7.2
CONFIG_BLKIO
Driver specific block device options for the nvme-io_uring backend.
7.2
CONFIG_BLKIO
Driver specific block device options for the virtio-blk-vfio-pci backend.
7.2
CONFIG_BLKIO
Driver specific block device options for the virtio-blk-vhost-user backend.
7.2
CONFIG_BLKIO
Driver specific block device options for the virtio-blk-vhost-vdpa backend.
7.2
CONFIG_BLKIO
An enumeration of libiscsi transport types
2.9
An enumeration of header digests supported by libiscsi
2.9
Driver specific block device options for iscsi
2.9
3.0
6.1
6.1
6.1
6.1
6.1
8.0
6.1
6.1
6.1
6.1
2.9
An enumeration of replication modes.
2.9
CONFIG_REPLICATION
Driver specific block device options for replication
2.9
CONFIG_REPLICATION
An enumeration of NFS transport types
2.9
Captures the address of the socket
2.9
Driver specific block device option for NFS
2.9
Driver specific block device options shared by all protocols supported by the curl backend.
2.9
Driver specific block device options for HTTP connections over the curl backend. URLs must start with "http://".
2.9
Driver specific block device options for HTTPS connections over the curl backend. URLs must start with "https://".
2.9
Driver specific block device options for FTP connections over the curl backend. URLs must start with "ftp://".
2.9
Driver specific block device options for FTPS connections over the curl backend. URLs must start with "ftps://".
2.9
Driver specific block device options for NBD.
2.9
Driver specific block device options for the raw driver.
2.9
Driver specific block device options for the throttle driver
2.11
Driver specific block device options for the copy-on-read driver.
6.0
An enumeration of possible behaviors for copy-before-write operation failures.
7.1
Driver specific block device options for the copy-before-write driver, which does so called copy-before-write operations: when data is written to the filter, the filter first reads corresponding blocks from its file child and copies them to target child. After successfully copying, the write request is propagated to file child. If copying fails, the original write request is failed too and no data is written to file child.
6.2
Options for creating a block device. Many options are available for all block devices, independent of the block driver:
2.9
Reference to a block device.
2.9
Reference to a block device.
2.9
Creates a new block device.
2.9
-> { "execute": "blockdev-add", "arguments": { "driver": "qcow2", "node-name": "test1", "file": { "driver": "file", "filename": "test.qcow2" } } } <- { "return": {} }
-> { "execute": "blockdev-add", "arguments": { "driver": "qcow2", "node-name": "node0", "discard": "unmap", "cache": { "direct": true }, "file": { "driver": "file", "filename": "/tmp/test.qcow2" }, "backing": { "driver": "raw", "file": { "driver": "file", "filename": "/dev/fdset/4" } } } } <- { "return": {} }
Reopens one or more block devices using the given set of options. Any option not specified will be reset to its default value regardless of its previous status. If an option cannot be changed or a particular driver does not support reopening then the command will return an error. All devices in the list are reopened in one transaction, so if one of them fails then the whole transaction is cancelled.
The command receives a list of block devices to reopen. For each one of them, the top-level node-name option (from BlockdevOptions) must be specified and is used to select the block device to be reopened. Other node-name options must be either omitted or set to the current name of the appropriate node. This command won't change any node name and any attempt to do it will result in an error.
In the case of options that refer to child nodes, the behavior of this command depends on the value:
Options (1) and (2) are supported in all cases. Option (3) is supported for file and backing, and option (4) for backing only.
Unlike with blockdev-add, the backing option must always be present unless the node being reopened does not have a backing file and its image does not have a default backing file name as part of its metadata.
6.1
Deletes a block device that has been added using blockdev-add. The command will fail if the node is attached to a device or is otherwise being used.
2.9
-> { "execute": "blockdev-add", "arguments": { "driver": "qcow2", "node-name": "node0", "file": { "driver": "file", "filename": "test.qcow2" } } } <- { "return": {} } -> { "execute": "blockdev-del", "arguments": { "node-name": "node0" } } <- { "return": {} }
Driver specific image creation options for file.
2.12
Driver specific image creation options for gluster.
2.12
Driver specific image creation options for LUKS.
2.12
Driver specific image creation options for NFS.
2.12
Driver specific image creation options for parallels.
2.12
Driver specific image creation options for qcow.
2.12
2.12
Compression type used in qcow2 image file
5.1
Driver specific image creation options for qcow2.
2.12
Driver specific image creation options for qed.
2.12
Driver specific image creation options for rbd/Ceph.
2.12
Subformat options for VMDK images
4.0
Adapter type info for VMDK images
4.0
Driver specific image creation options for VMDK.
4.0
Driver specific image creation options for SSH.
2.12
Driver specific image creation options for VDI.
2.12
2.12
Driver specific image creation options for vhdx.
2.12
2.12
Driver specific image creation options for vpc (VHD).
2.12
Options for creating an image format on a given node.
2.12
Starts a job to create an image format on a given node. The job is automatically finalized, but a manual job-dismiss is required.
3.0
Driver specific image amend options for LUKS.
5.1
Driver specific image amend options for qcow2. For now, only encryption options can be amended
5.1
Options for amending an image format
5.1
Starts a job to amend format specific options of an existing open block device The job is automatically finalized, but a manual job-dismiss is required.
5.1
An enumeration of action that has been taken when a DISK I/O occurs
2.1
Emitted when a disk image is being marked corrupt. The image can be identified by its device or node name. The 'device' field is always present for compatibility reasons, but it can be empty ("") if the image does not have a device name associated.
NOTE:
<- { "event": "BLOCK_IMAGE_CORRUPTED", "data": { "device": "", "node-name": "drive", "fatal": false, "msg": "L2 table offset 0x2a2a2a00 unaligned (L1 index: 0)" }, "timestamp": { "seconds": 1648243240, "microseconds": 906060 } }
1.7
Emitted when a disk I/O error occurs
NOTE:
NOTE:
0.13
<- { "event": "BLOCK_IO_ERROR", "data": { "qom-path": "/machine/unattached/device[0]", "device": "ide0-hd1", "node-name": "#block212", "operation": "write", "action": "stop", "reason": "No space left on device" }, "timestamp": { "seconds": 1265044230, "microseconds": 450486 } }
Emitted when a block job has completed
1.1
<- { "event": "BLOCK_JOB_COMPLETED", "data": { "type": "stream", "device": "virtio-disk0", "len": 10737418240, "offset": 10737418240, "speed": 0 }, "timestamp": { "seconds": 1267061043, "microseconds": 959568 } }
Emitted when a block job has been cancelled
1.1
<- { "event": "BLOCK_JOB_CANCELLED", "data": { "type": "stream", "device": "virtio-disk0", "len": 10737418240, "offset": 134217728, "speed": 0 }, "timestamp": { "seconds": 1267061043, "microseconds": 959568 } }
Emitted when a block job encounters an error
1.3
<- { "event": "BLOCK_JOB_ERROR", "data": { "device": "ide0-hd1", "operation": "write", "action": "stop" }, "timestamp": { "seconds": 1265044230, "microseconds": 450486 } }
Emitted when a block job is ready to complete
NOTE:
1.3
<- { "event": "BLOCK_JOB_READY", "data": { "device": "drive0", "type": "mirror", "speed": 0, "len": 2097152, "offset": 2097152 }, "timestamp": { "seconds": 1265044230, "microseconds": 450486 } }
Emitted when a block job is awaiting explicit authorization to finalize graph changes via block-job-finalize. If this job is part of a transaction, it will not emit this event until the transaction has converged first.
2.12
<- { "event": "BLOCK_JOB_PENDING", "data": { "type": "mirror", "id": "backup_1" }, "timestamp": { "seconds": 1265044230, "microseconds": 450486 } }
Preallocation mode of QEMU image file
2.2
Emitted when writes on block device reaches or exceeds the configured write threshold. For thin-provisioned devices, this means the device should be extended to avoid pausing for disk exhaustion. The event is one shot. Once triggered, it needs to be re-registered with another block-set-write-threshold command.
2.3
Change the write threshold for a block drive. An event will be delivered if a write to this block drive crosses the configured threshold. The threshold is an offset, thus must be non-negative. Default is no write threshold. Setting the threshold to zero disables it.
This is useful to transparently resize thin-provisioned drives without the guest OS noticing.
2.3
-> { "execute": "block-set-write-threshold", "arguments": { "node-name": "mydev", "write-threshold": 17179869184 } } <- { "return": {} }
Dynamically reconfigure the block driver state graph. It can be used to add, remove, insert or replace a graph node. Currently only the Quorum driver implements this feature to add or remove its child. This is useful to fix a broken quorum child.
If node is specified, it will be inserted under parent. child may not be specified in this case. If both parent and child are specified but node is not, child will be detached from parent.
FIXME Removing children from a quorum node means introducing gaps in the child indices. This cannot be represented in the 'children' list of BlockdevOptionsQuorum, as returned by .bdrv_refresh_filename().
Warning: The data in a new quorum child MUST be consistent with that of the rest of the array.
2.7
-> { "execute": "blockdev-add", "arguments": { "driver": "raw", "node-name": "new_node", "file": { "driver": "file", "filename": "test.raw" } } } <- { "return": {} } -> { "execute": "x-blockdev-change", "arguments": { "parent": "disk1", "node": "new_node" } } <- { "return": {} }
-> { "execute": "x-blockdev-change", "arguments": { "parent": "disk1", "child": "children.1" } } <- { "return": {} }
Move node and its children into the iothread. If iothread is null then move node and its children into the main loop.
The node must not be attached to a BlockBackend.
2.12
-> { "execute": "x-blockdev-set-iothread", "arguments": { "node-name": "disk1", "iothread": "iothread0" } } <- { "return": {} }
-> { "execute": "x-blockdev-set-iothread", "arguments": { "node-name": "disk1", "iothread": null } } <- { "return": {} }
An enumeration of the quorum operation types
2.6
Emitted by the Quorum block driver if it fails to establish a quorum
NOTE:
2.0
<- { "event": "QUORUM_FAILURE", "data": { "reference": "usr1", "sector-num": 345435, "sectors-count": 5 }, "timestamp": { "seconds": 1344522075, "microseconds": 745528 } }
Emitted to report a corruption of a Quorum file
NOTE:
2.0
<- { "event": "QUORUM_REPORT_BAD", "data": { "node-name": "node0", "sector-num": 345435, "sectors-count": 5, "type": "read" }, "timestamp": { "seconds": 1344522075, "microseconds": 745528 } }
<- { "event": "QUORUM_REPORT_BAD", "data": { "node-name": "node0", "sector-num": 0, "sectors-count": 2097120, "type": "flush", "error": "Broken pipe" }, "timestamp": { "seconds": 1456406829, "microseconds": 291763 } }
1.7
Synchronously take an internal snapshot of a block device, when the format of the image used supports it. If the name is an empty string, or a snapshot with name already exists, the operation will fail.
NOTE:
1.7
-> { "execute": "blockdev-snapshot-internal-sync", "arguments": { "device": "ide-hd0", "name": "snapshot0" } } <- { "return": {} }
Synchronously delete an internal snapshot of a block device, when the format of the image used support it. The snapshot is identified by name or id or both. One of the name or id is required. Return SnapshotInfo for the successfully deleted snapshot.
SnapshotInfo
1.7
-> { "execute": "blockdev-snapshot-delete-internal-sync", "arguments": { "device": "ide-hd0", "name": "snapshot0" } } <- { "return": { "id": "1", "name": "snapshot0", "vm-state-size": 0, "date-sec": 1000012, "date-nsec": 10, "vm-clock-sec": 100, "vm-clock-nsec": 20, "icount": 220414 } }
Not used by QMP; hack to let us use BlockGraphInfoList internally
8.0
Keep this type consistent with the nbd-server-start arguments. The only intended difference is using SocketAddress instead of SocketAddressLegacy.
4.2
Start an NBD server listening on the given host and port. Block devices can then be exported using nbd-server-add. The NBD server will present them as named exports; for example, another QEMU instance could refer to them as "nbd:HOST:PORT:exportname=NAME".
Keep this type consistent with the NbdServerOptions type. The only intended difference is using SocketAddressLegacy instead of SocketAddress.
1.3
An NBD block export (common options shared between nbd-server-add and the NBD branch of block-export-add).
5.0
An NBD block export (distinct options used in the NBD branch of block-export-add).
5.2
A vhost-user-blk block export.
5.2
Possible allow_other modes for FUSE exports.
6.1
Options for exporting a block graph node on some (file) mountpoint as a raw image.
6.0
CONFIG_FUSE
A vduse-blk block export.
7.1
An NBD block export, per legacy nbd-server-add command.
5.0
Export a block node to QEMU's embedded NBD server.
The export name will be used as the id for the resulting block export.
1.3
Mode for removing a block export.
2.12
Remove NBD export by name.
2.12
Stop QEMU's embedded NBD server, and unregister all devices previously added via nbd-server-add.
1.3
An enumeration of block export types
4.2
Describes a block export, i.e. how single node should be exported on an external interface.
4.2
Creates a new block export.
5.2
Request to remove a block export. This drops the user's reference to the export, but the export may still stay around after this command returns until the shutdown of the export has completed.
5.2
Emitted when a block export is removed and its id can be reused.
5.2
Information about a single block export.
5.2
A list of BlockExportInfo describing all block exports
5.2
Information about a character device.
NOTE:
0.14
Returns information about current character devices.
a list of ChardevInfo
0.14
-> { "execute": "query-chardev" } <- { "return": [ { "label": "charchannel0", "filename": "unix:/var/lib/libvirt/qemu/seabios.rhel6.agent,server=on", "frontend-open": false }, { "label": "charmonitor", "filename": "unix:/var/lib/libvirt/qemu/seabios.rhel6.monitor,server=on", "frontend-open": true }, { "label": "charserial0", "filename": "pty:/dev/pts/2", "frontend-open": true } ] }
Information about a character device backend
2.0
Returns information about character device backends.
a list of ChardevBackendInfo
2.0
-> { "execute": "query-chardev-backends" } <- { "return":[ { "name":"udp" }, { "name":"tcp" }, { "name":"unix" }, { "name":"spiceport" } ] }
An enumeration of data format.
1.4
Write to a ring buffer character device.
1.4
-> { "execute": "ringbuf-write", "arguments": { "device": "foo", "data": "abcdefgh", "format": "utf8" } } <- { "return": {} }
Read from a ring buffer character device.
data read from the device
1.4
-> { "execute": "ringbuf-read", "arguments": { "device": "foo", "size": 1000, "format": "utf8" } } <- { "return": "abcdefgh" }
Configuration shared across all chardev backends
2.6
Configuration info for file chardevs.
1.4
Configuration info for device and pipe chardevs.
1.4
Configuration info for (stream) socket chardevs.
1.4
Configuration info for datagram socket chardevs.
1.5
Configuration info for mux chardevs.
1.5
Configuration info for stdio chardevs.
1.5
Configuration info for spice vm channel chardevs.
1.5
CONFIG_SPICE
Configuration info for spice port chardevs.
1.5
CONFIG_SPICE
Configuration info for DBus chardevs.
7.0
CONFIG_DBUS_DISPLAY
Configuration info for virtual console chardevs.
NOTE:
1.5
Configuration info for ring buffer chardevs.
1.5
Configuration info for qemu vdagent implementation.
6.1
CONFIG_SPICE_PROTOCOL
Configuration info for pty implementation.
9.2
1.4
1.4
1.4
1.4
1.5
2.6
1.5
1.5
1.5
CONFIG_SPICE
1.5
CONFIG_SPICE
6.1
CONFIG_SPICE_PROTOCOL
7.0
CONFIG_DBUS_DISPLAY
1.5
1.5
9.2
Configuration info for the new chardev backend.
1.4
Return info about the chardev backend just created.
1.4
Add a character device backend
ChardevReturn.
1.4
-> { "execute" : "chardev-add", "arguments" : { "id" : "foo", "backend" : { "type" : "null", "data" : {} } } } <- { "return": {} }
-> { "execute" : "chardev-add", "arguments" : { "id" : "bar", "backend" : { "type" : "file", "data" : { "out" : "/tmp/bar.log" } } } } <- { "return": {} }
-> { "execute" : "chardev-add", "arguments" : { "id" : "baz", "backend" : { "type" : "pty", "data" : {} } } } <- { "return": { "pty" : "/dev/pty/42" } }
Change a character device backend
ChardevReturn.
2.10
-> { "execute" : "chardev-change", "arguments" : { "id" : "baz", "backend" : { "type" : "pty", "data" : {} } } } <- { "return": { "pty" : "/dev/pty/42" } }
-> {"execute" : "chardev-change", "arguments" : { "id" : "charchannel2", "backend" : { "type" : "socket", "data" : { "addr" : { "type" : "unix" , "data" : { "path" : "/tmp/charchannel2.socket" } }, "server" : true, "wait" : false }}}} <- {"return": {}}
Remove a character device backend
1.4
Send a break to a character device
2.10
Emitted when the guest opens or closes a virtio-serial port.
NOTE:
2.1
<- { "event": "VSERPORT_CHANGE", "data": { "id": "channel0", "open": true }, "timestamp": { "seconds": 1401385907, "microseconds": 422329 } }
The authorization policy result
4.0
The authorization policy match format
4.0
A single authorization rule.
4.0
Properties for authz-list objects.
4.0
Properties for authz-listfile objects.
4.0
Properties for authz-pam objects.
4.0
Properties for authz-simple objects.
4.0
This action can be used to test transaction failure.
1.6
An enumeration of Transactional completion modes.
2.5
1.1
1.6
2.5
2.5
4.0
2.3
2.5
1.7
1.1
1.6
A discriminated record of operations that can be performed with transaction.
1.1
Optional arguments to modify the behavior of a Transaction.
2.5
Executes a number of transactionable QMP commands atomically. If any operation fails, then the entire set of actions will be abandoned and the appropriate error returned.
For external snapshots, the dictionary contains the device, the file to use for the new snapshot, and the format. The default format, if not specified, is qcow2.
Each new snapshot defaults to being created by QEMU (wiping any contents if the file already exists), but it is also possible to reuse an externally-created file. In the latter case, you should ensure that the new image file has the same contents as the current one; QEMU cannot perform any meaningful check. Typically this is achieved by using the current image file as the backing file for the new image.
On failure, the original disks pre-snapshot attempt will be used.
For internal snapshots, the dictionary contains the device and the snapshot's name. If an internal snapshot matching name already exists, the request will be rejected. Only some image formats support it, for example, qcow2, and rbd,
On failure, qemu will try delete the newly created internal snapshot in the transaction. When an I/O error occurs during deletion, the user needs to fix it later with qemu-img or other command.
NOTE:
1.1
-> { "execute": "transaction", "arguments": { "actions": [ { "type": "blockdev-snapshot-sync", "data" : { "device": "ide-hd0", "snapshot-file": "/some/place/my-image", "format": "qcow2" } }, { "type": "blockdev-snapshot-sync", "data" : { "node-name": "myfile", "snapshot-file": "/some/place/my-image2", "snapshot-node-name": "node3432", "mode": "existing", "format": "qcow2" } }, { "type": "blockdev-snapshot-sync", "data" : { "device": "ide-hd1", "snapshot-file": "/some/place/my-image2", "mode": "existing", "format": "qcow2" } }, { "type": "blockdev-snapshot-internal-sync", "data" : { "device": "ide-hd2", "name": "snapshot0" } } ] } } <- { "return": {} }
Enable QMP capabilities.
-> { "execute": "qmp_capabilities", "arguments": { "enable": [ "oob" ] } } <- { "return": {} }
NOTE:
NOTE:
0.13
Enumeration of capabilities to be advertised during initial client connection, used for agreeing on particular QMP extension behaviors.
2.12
A three-part version number.
2.4
A description of QEMU's version.
0.14
Returns the current version of QEMU.
A VersionInfo object describing the current version of QEMU.
0.14
-> { "execute": "query-version" } <- { "return":{ "qemu":{ "major":0, "minor":11, "micro":5 }, "package":"" } }
Information about a QMP command
0.14
Return a list of supported QMP commands by this server
A list of CommandInfo for all supported commands
0.14
-> { "execute": "query-commands" } <- { "return":[ { "name":"query-balloon" }, { "name":"system_powerdown" }, ... ] }
This example has been shortened as the real response is too long.
This command will cause the QEMU process to exit gracefully. While every attempt is made to send the QMP response before terminating, this is not guaranteed. When using this interface, a premature EOF would not be unexpected.
0.14
An enumeration of monitor modes.
5.0
Options to be used for adding a new monitor.
5.0
Command query-qmp-schema exposes the QMP wire ABI as an array of SchemaInfo. This lets QMP clients figure out what commands and events are available in this QEMU, and their parameters and results.
However, the SchemaInfo can't reflect all the rules and restrictions that apply to QMP. It's interface introspection (figuring out what's there), not interface specification. The specification is in the QAPI schema.
Furthermore, while we strive to keep the QMP wire format backwards-compatible across qemu versions, the introspection output is not guaranteed to have the same stability. For example, one version of qemu may list an object member as an optional non-variant, while another lists the same member only through the object's variants; or the type of a member may change from a generic string into a specific enum or from one specific type into an alternate that includes the original type alongside something else.
array of SchemaInfo, where each element describes an entity in the ABI: command, event, type, ...
The order of the various SchemaInfo is unspecified; however, all names are guaranteed to be unique (no name will be duplicated with different meta-types).
NOTE:
2.5
This is a SchemaInfo's meta type, i.e. the kind of entity it describes.
2.5
2.5
Additional SchemaInfo members for meta-type 'builtin'.
2.5
The four primitive and two structured types according to RFC 8259 section 1, plus 'int' (split off 'number'), plus the obvious top type 'value'.
2.5
Additional SchemaInfo members for meta-type 'enum'.
Values of this type are JSON string on the wire.
2.5
An object member.
6.2
Additional SchemaInfo members for meta-type 'array'.
Values of this type are JSON array on the wire.
2.5
Additional SchemaInfo members for meta-type 'object'.
Values of this type are JSON object on the wire.
2.5
An object member.
2.5
The variant members for a value of the type tag.
2.5
Additional SchemaInfo members for meta-type 'alternate'.
On the wire, this can be any of the members.
2.5
An alternate member.
2.5
Additional SchemaInfo members for meta-type 'command'.
2.5
Additional SchemaInfo members for meta-type 'event'.
2.5
1.2
This command will list any properties of a object given a path in the object model.
a list of ObjectPropertyInfo that describe the properties of the object.
1.2
-> { "execute": "qom-list", "arguments": { "path": "/chardevs" } } <- { "return": [ { "name": "type", "type": "string" }, { "name": "parallel0", "type": "child<chardev-vc>" }, { "name": "serial0", "type": "child<chardev-vc>" }, { "name": "mon0", "type": "child<chardev-stdio>" } ] }
This command will get a property from a object model path and return the value.
Absolute paths are derived from the root object and can follow child<> or link<> properties. Since they can follow link<> properties, they can be arbitrarily long. Absolute paths look like absolute filenames and are prefixed with a leading slash.
Partial paths look like relative filenames. They do not begin with a prefix. The matching rules for partial paths are subtle but designed to make specifying objects easy. At each level of the composition tree, the partial path is matched as an absolute path. The first match is not returned. At least two matches are searched for. A successful result is only returned if only one match is found. If more than one match is found, a flag is return to indicate that the match was ambiguous.
The property value. The type depends on the property type. child<> and link<> properties are returned as #str pathnames. All integer property types (u8, u16, etc) are returned as #int.
1.2
-> { "execute": "qom-get", "arguments": { "path": "/machine/unattached/device[0]", "property": "hotplugged" } } <- { "return": false }
-> { "execute": "qom-get", "arguments": { "path": "unattached/sysbus", "property": "type" } } <- { "return": "System" }
This command will set a property from a object model path.
1.2
-> { "execute": "qom-set", "arguments": { "path": "/machine", "property": "graphics", "value": false } } <- { "return": {} }
This structure describes a search result from qom-list-types
1.1
This command will return a list of types given search parameters
a list of ObjectTypeInfo or an empty list if no results are found
1.1
List properties associated with a QOM object.
NOTE:
a list of ObjectPropertyInfo describing object properties
2.12
Properties for can-host-socketcan objects.
2.12
CONFIG_LINUX
Properties for colo-compare objects.
2.8
Properties for cryptodev-backend and cryptodev-backend-builtin objects.
2.8
Properties for cryptodev-vhost-user objects.
2.12
CONFIG_VHOST_CRYPTO
Properties for dbus-vmstate objects.
5.0
Indicates where to insert a netfilter relative to a given other filter.
5.0
Properties for objects of classes derived from netfilter.
2.5
Properties for filter-buffer objects.
2.5
Properties for filter-dump objects.
2.5
Properties for filter-mirror objects.
2.6
Properties for filter-redirector objects.
At least one of indev or outdev must be present. If both are present, they must not refer to the same character device backend.
2.6
Properties for filter-rewriter objects.
2.8
Properties for input-barrier objects.
4.2
Properties for input-linux objects.
2.6
CONFIG_LINUX
Common properties for event loops
7.1
Properties for iothread objects.
The aio-max-batch option is available since 6.1.
2.0
Properties for the main-loop object.
7.1
Properties for objects of classes derived from memory-backend.
NOTE:
2.1
Properties for memory-backend-file objects.
2.1
Properties for memory-backend-memfd objects.
2.12
CONFIG_LINUX
Properties for memory-backend-shm objects.
This memory backend supports only shared memory, which is the default.
9.1
CONFIG_POSIX
Properties for memory-backend-epc objects.
The merge boolean option is false by default with epc
The dump boolean option is false by default with epc
6.2
CONFIG_LINUX
Properties for pr-manager-helper objects.
2.11
CONFIG_LINUX
Properties for qtest objects.
6.0
Properties for x-remote-object objects.
6.0
Properties for x-vfio-user-server objects.
7.1
Properties for iommufd objects.
9.0
Properties for acpi-generic-initiator objects.
9.0
Properties for acpi-generic-port objects.
9.2
Properties for objects of classes derived from rng.
1.3
Properties for rng-egd objects.
1.3
Properties for rng-random objects.
1.3
CONFIG_POSIX
Properties common to objects that are derivatives of sev-common.
9.1
Properties for sev-guest objects.
2.12
Properties for sev-snp-guest objects. Most of these are direct arguments for the KVM_SNP_* interfaces documented in the Linux kernel source under Documentation/arch/x86/amd-memory-encryption.rst, which are in turn closely coupled with the SNP_INIT/SNP_LAUNCH_* firmware commands documented in the SEV-SNP Firmware ABI Specification (Rev 0.9).
More usage information is also available in the QEMU source tree under docs/amd-memory-encryption.
9.1
Properties for thread context objects.
7.2
6.0
Describes the options of a user creatable QOM object.
6.0
Create a QOM object.
2.0
-> { "execute": "object-add", "arguments": { "qom-type": "rng-random", "id": "rng1", "filename": "/dev/hwrng" } } <- { "return": {} }
Remove a QOM object.
2.0
2024, The QEMU Project Developers
January 12, 2025 | 9.2.0 |