mirror of
https://github.com/qemu/qemu.git
synced 2025-08-11 15:10:13 +00:00

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
219 lines
6.3 KiB
Plaintext
219 lines
6.3 KiB
Plaintext
QMP Supported Commands
|
|
----------------------
|
|
|
|
This document describes all commands currently supported by QMP.
|
|
|
|
Most of the time their usage is exactly the same as in the user Monitor, this
|
|
means that any other document which also describe commands (the manpage,
|
|
QEMU's manual, etc) can and should be consulted.
|
|
|
|
QMP has two types of commands: regular and query commands. Regular commands
|
|
usually change the Virtual Machine's state someway, while query commands just
|
|
return information. The sections below are divided accordingly.
|
|
|
|
It's important to observe that all communication examples are formatted in
|
|
a reader-friendly way, so that they're easier to understand. However, in real
|
|
protocol usage, they're emitted as a single line.
|
|
|
|
Also, the following notation is used to denote data flow:
|
|
|
|
-> data issued by the Client
|
|
<- Server data response
|
|
|
|
Please, refer to the QMP specification (docs/qmp-spec.txt) for detailed
|
|
information on the Server command and response formats.
|
|
|
|
NOTE: This document is temporary and will be replaced soon.
|
|
|
|
1. Stability Considerations
|
|
===========================
|
|
|
|
The current QMP command set (described in this file) may be useful for a
|
|
number of use cases, however it's limited and several commands have bad
|
|
defined semantics, specially with regard to command completion.
|
|
|
|
These problems are going to be solved incrementally in the next QEMU releases
|
|
and we're going to establish a deprecation policy for badly defined commands.
|
|
|
|
If you're planning to adopt QMP, please observe the following:
|
|
|
|
1. The deprecation policy will take effect and be documented soon, please
|
|
check the documentation of each used command as soon as a new release of
|
|
QEMU is available
|
|
|
|
2. DO NOT rely on anything which is not explicit documented
|
|
|
|
3. Errors, in special, are not documented. Applications should NOT check
|
|
for specific errors classes or data (it's strongly recommended to only
|
|
check for the "error" key)
|
|
|
|
2. Regular Commands
|
|
===================
|
|
|
|
Server's responses in the examples below are always a success response, please
|
|
refer to the QMP specification for more details on error responses.
|
|
|
|
device_add
|
|
----------
|
|
|
|
Add a device.
|
|
|
|
Arguments:
|
|
|
|
- "driver": the name of the new device's driver (json-string)
|
|
- "bus": the device's parent bus (device tree path, json-string, optional)
|
|
- "id": the device's ID, must be unique (json-string)
|
|
- device properties
|
|
|
|
Example:
|
|
|
|
-> { "execute": "device_add", "arguments": { "driver": "e1000", "id": "net1" } }
|
|
<- { "return": {} }
|
|
|
|
Notes:
|
|
|
|
(1) For detailed information about this command, please refer to the
|
|
'docs/qdev-device-use.txt' file.
|
|
|
|
(2) It's possible to list device properties by running QEMU with the
|
|
"-device DEVICE,\?" command-line argument, where DEVICE is the device's name
|
|
|
|
cpu
|
|
---
|
|
|
|
Set the default CPU.
|
|
|
|
Arguments:
|
|
|
|
- "index": the CPU's index (json-int)
|
|
|
|
Example:
|
|
|
|
-> { "execute": "cpu", "arguments": { "index": 0 } }
|
|
<- { "return": {} }
|
|
|
|
Note: CPUs' indexes are obtained with the 'query-cpus' command.
|
|
|
|
xen-load-devices-state
|
|
----------------------
|
|
|
|
Load the state of all devices from file. The RAM and the block devices
|
|
of the VM are not loaded by this command.
|
|
|
|
Arguments:
|
|
|
|
- "filename": the file to load the state of the devices from as binary
|
|
data. See xen-save-devices-state.txt for a description of the binary
|
|
format.
|
|
|
|
Example:
|
|
|
|
-> { "execute": "xen-load-devices-state",
|
|
"arguments": { "filename": "/tmp/resume" } }
|
|
<- { "return": {} }
|
|
|
|
migrate-set-cache-size
|
|
----------------------
|
|
|
|
Set cache size to be used by XBZRLE migration, the cache size will be rounded
|
|
down to the nearest power of 2
|
|
|
|
Arguments:
|
|
|
|
- "value": cache size in bytes (json-int)
|
|
|
|
Example:
|
|
|
|
-> { "execute": "migrate-set-cache-size", "arguments": { "value": 536870912 } }
|
|
<- { "return": {} }
|
|
|
|
x-colo-lost-heartbeat
|
|
--------------------
|
|
|
|
Tell COLO that heartbeat is lost, a failover or takeover is needed.
|
|
|
|
Example:
|
|
|
|
-> { "execute": "x-colo-lost-heartbeat" }
|
|
<- { "return": {} }
|
|
|
|
query-dump
|
|
----------
|
|
|
|
Query background dump status.
|
|
|
|
Arguments: None.
|
|
|
|
Example:
|
|
|
|
-> { "execute": "query-dump" }
|
|
<- { "return": { "status": "active", "completed": 1024000,
|
|
"total": 2048000 } }
|
|
|
|
blockdev-mirror
|
|
------------
|
|
|
|
Start mirroring a block device's writes to another block device. target
|
|
specifies the target of mirror operation.
|
|
|
|
Arguments:
|
|
|
|
- "job-id": Identifier for the newly-created block job. If omitted,
|
|
the device name will be used. (json-string, optional)
|
|
- "device": The device name or node-name of a root node whose writes should be
|
|
mirrored (json-string)
|
|
- "target": device name to mirror to (json-string)
|
|
- "replaces": the block driver node name to replace when finished
|
|
(json-string, optional)
|
|
- "speed": maximum speed of the streaming job, in bytes per second
|
|
(json-int)
|
|
- "granularity": granularity of the dirty bitmap, in bytes (json-int, optional)
|
|
- "buf_size": maximum amount of data in flight from source to target, in bytes
|
|
(json-int, default 10M)
|
|
- "sync": what parts of the disk image should be copied to the destination;
|
|
possibilities include "full" for all the disk, "top" for only the sectors
|
|
allocated in the topmost image, or "none" to only replicate new I/O
|
|
(MirrorSyncMode).
|
|
- "on-source-error": the action to take on an error on the source
|
|
(BlockdevOnError, default 'report')
|
|
- "on-target-error": the action to take on an error on the target
|
|
(BlockdevOnError, default 'report')
|
|
|
|
The default value of the granularity is the image cluster size clamped
|
|
between 4096 and 65536, if the image format defines one. If the format
|
|
does not define a cluster size, the default value of the granularity
|
|
is 65536.
|
|
|
|
Example:
|
|
|
|
-> { "execute": "blockdev-mirror", "arguments": { "device": "ide-hd0",
|
|
"target": "target0",
|
|
"sync": "full" } }
|
|
<- { "return": {} }
|
|
|
|
qmp_capabilities
|
|
----------------
|
|
|
|
Enable QMP capabilities.
|
|
|
|
Arguments: None.
|
|
|
|
Example:
|
|
|
|
-> { "execute": "qmp_capabilities" }
|
|
<- { "return": {} }
|
|
|
|
Note: This command must be issued before issuing any other command.
|
|
|
|
3. Query Commands
|
|
=================
|
|
|
|
|
|
query-qmp-schema
|
|
----------------
|
|
|
|
Return the QMP wire schema. The returned value is a json-array of
|
|
named schema entities. Entities are commands, events and various
|
|
types. See docs/qapi-code-gen.txt for information on their structure
|
|
and intended use.
|