a93b9ba76f
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
335 lines
10 KiB
Plaintext
335 lines
10 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.
|
|
|
|
x-blockdev-change
|
|
-----------------
|
|
|
|
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.
|
|
|
|
Arguments:
|
|
- "parent": the id or name of the parent node (json-string)
|
|
- "child": the name of a child under the given parent node (json-string, optional)
|
|
- "node": the name of the node that will be added (json-string, optional)
|
|
|
|
Note: this command is experimental, and not a stable API. It doesn't
|
|
support all kinds of operations, all kinds of children, nor all block
|
|
drivers.
|
|
|
|
Warning: The data in a new quorum child MUST be consistent with that of
|
|
the rest of the array.
|
|
|
|
Example:
|
|
|
|
Add a new node to a quorum
|
|
-> { "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": {} }
|
|
|
|
Delete a quorum's node
|
|
-> { "execute": "x-blockdev-change",
|
|
"arguments": { "parent": "disk1",
|
|
"child": "children.1" } }
|
|
<- { "return": {} }
|
|
|
|
trace-event-set-state
|
|
---------------------
|
|
|
|
Set the state of events.
|
|
|
|
Arguments:
|
|
|
|
- "name": Event name pattern (json-string).
|
|
- "enable": Whether to enable or disable the event (json-bool).
|
|
- "ignore-unavailable": Whether to ignore errors for events that cannot be
|
|
changed (json-bool, optional).
|
|
- "vcpu": The vCPU to act upon, all vCPUs by default (json-int, optional).
|
|
|
|
An event's state is modified if:
|
|
- its name matches the "name" pattern, and
|
|
- if "vcpu" is given, the event has the "vcpu" property.
|
|
|
|
Therefore, if "vcpu" is given, the operation will only match per-vCPU events,
|
|
setting their state on the specified vCPU. Special case: if "name" is an exact
|
|
match, "vcpu" is given and the event does not have the "vcpu" property, an error
|
|
is returned.
|
|
|
|
Example:
|
|
|
|
-> { "execute": "trace-event-set-state", "arguments": { "name": "qemu_memalign", "enable": "true" } }
|
|
<- { "return": {} }
|
|
|
|
query-gic-capabilities
|
|
---------------
|
|
|
|
Return a list of GICCapability objects, describing supported GIC
|
|
(Generic Interrupt Controller) versions.
|
|
|
|
Arguments: None
|
|
|
|
Example:
|
|
|
|
-> { "execute": "query-gic-capabilities" }
|
|
<- { "return": [{ "version": 2, "emulated": true, "kernel": false },
|
|
{ "version": 3, "emulated": false, "kernel": true } ] }
|
|
|
|
Show existing/possible CPUs
|
|
---------------------------
|
|
|
|
Arguments: None.
|
|
|
|
Example for pseries machine type started with
|
|
-smp 2,cores=2,maxcpus=4 -cpu POWER8:
|
|
|
|
-> { "execute": "query-hotpluggable-cpus" }
|
|
<- {"return": [
|
|
{ "props": { "core-id": 8 }, "type": "POWER8-spapr-cpu-core",
|
|
"vcpus-count": 1 },
|
|
{ "props": { "core-id": 0 }, "type": "POWER8-spapr-cpu-core",
|
|
"vcpus-count": 1, "qom-path": "/machine/unattached/device[0]"}
|
|
]}'
|
|
|
|
Example for pc machine type started with
|
|
-smp 1,maxcpus=2:
|
|
-> { "execute": "query-hotpluggable-cpus" }
|
|
<- {"return": [
|
|
{
|
|
"type": "qemu64-x86_64-cpu", "vcpus-count": 1,
|
|
"props": {"core-id": 0, "socket-id": 1, "thread-id": 0}
|
|
},
|
|
{
|
|
"qom-path": "/machine/unattached/device[0]",
|
|
"type": "qemu64-x86_64-cpu", "vcpus-count": 1,
|
|
"props": {"core-id": 0, "socket-id": 0, "thread-id": 0}
|
|
}
|
|
]}
|