2010-09-13 19:26:00 +04:00
|
|
|
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
|
|
|
|
|
2016-10-06 18:10:00 +03:00
|
|
|
Please, refer to the QMP specification (docs/qmp-spec.txt) for detailed
|
2010-09-13 19:26:00 +04:00
|
|
|
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:
|
|
|
|
|
2011-07-27 10:32:56 +04:00
|
|
|
1. The deprecation policy will take effect and be documented soon, please
|
2010-09-13 19:26:00 +04:00
|
|
|
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.
|
|
|
|
|
2016-06-03 12:58:34 +03:00
|
|
|
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": {} }
|
|
|
|
|
2012-08-06 22:42:54 +04:00
|
|
|
migrate-set-cache-size
|
2013-02-11 18:11:10 +04:00
|
|
|
----------------------
|
2012-08-06 22:42:54 +04:00
|
|
|
|
|
|
|
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": {} }
|
|
|
|
|
COLO: Add 'x-colo-lost-heartbeat' command to trigger failover
We leave users to choose whatever heartbeat solution they want,
if the heartbeat is lost, or other errors they detect, they can use
experimental command 'x_colo_lost_heartbeat' to tell COLO to do failover,
COLO will do operations accordingly.
For example, if the command is sent to the Primary side,
the Primary side will exit COLO mode, does cleanup work,
and then, PVM will take over the service work. If sent to the Secondary side,
the Secondary side will run failover work, then takes over PVM's service work.
Cc: Luiz Capitulino <lcapitulino@redhat.com>
Cc: Eric Blake <eblake@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>
Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Amit Shah <amit.shah@redhat.com>
Signed-off-by: Amit Shah <amit@amitshah.net>
2016-10-27 09:43:03 +03:00
|
|
|
x-colo-lost-heartbeat
|
|
|
|
--------------------
|
|
|
|
|
|
|
|
Tell COLO that heartbeat is lost, a failover or takeover is needed.
|
|
|
|
|
|
|
|
Example:
|
|
|
|
|
|
|
|
-> { "execute": "x-colo-lost-heartbeat" }
|
|
|
|
<- { "return": {} }
|
|
|
|
|
2016-02-18 08:16:54 +03:00
|
|
|
query-dump
|
|
|
|
----------
|
|
|
|
|
|
|
|
Query background dump status.
|
|
|
|
|
|
|
|
Arguments: None.
|
|
|
|
|
|
|
|
Example:
|
|
|
|
|
|
|
|
-> { "execute": "query-dump" }
|
|
|
|
<- { "return": { "status": "active", "completed": 1024000,
|
|
|
|
"total": 2048000 } }
|
|
|
|
|
2015-12-24 07:45:05 +03:00
|
|
|
blockdev-mirror
|
|
|
|
------------
|
|
|
|
|
|
|
|
Start mirroring a block device's writes to another block device. target
|
|
|
|
specifies the target of mirror operation.
|
|
|
|
|
|
|
|
Arguments:
|
|
|
|
|
2016-07-05 17:28:57 +03:00
|
|
|
- "job-id": Identifier for the newly-created block job. If omitted,
|
|
|
|
the device name will be used. (json-string, optional)
|
2016-06-23 15:20:24 +03:00
|
|
|
- "device": The device name or node-name of a root node whose writes should be
|
|
|
|
mirrored (json-string)
|
2015-12-24 07:45:05 +03:00
|
|
|
- "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": {} }
|
|
|
|
|
2010-09-13 19:26:00 +04:00
|
|
|
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
|
|
|
|
=================
|
|
|
|
|
|
|
|
|
qapi: New QMP command query-qmp-schema for QMP introspection
qapi/introspect.json defines the introspection schema. It's designed
for QMP introspection, but should do for similar uses, such as QGA.
The introspection schema does not reflect all the rules and
restrictions that apply to QAPI schemata. A valid QAPI schema has an
introspection value conforming to the introspection schema, but the
converse is not true.
Introspection lowers away a number of schema details, and makes
implicit things explicit:
* The built-in types are declared with their JSON type.
All integer types are mapped to 'int', because how many bits we use
internally is an implementation detail. It could be pressed into
external interface service as very approximate range information,
but that's a bad idea. If we need range information, we better do
it properly.
* Implicit type definitions are made explicit, and given
auto-generated names:
- Array types, named by appending "List" to the name of their
element type, like in generated C.
- The enumeration types implicitly defined by simple union types,
named by appending "Kind" to the name of their simple union type,
like in generated C.
- Types that don't occur in generated C. Their names start with ':'
so they don't clash with the user's names.
* All type references are by name.
* The struct and union types are generalized into an object type.
* Base types are flattened.
* Commands take a single argument and return a single result.
Dictionary argument or list result is an implicit type definition.
The empty object type is used when a command takes no arguments or
produces no results.
The argument is always of object type, but the introspection schema
doesn't reflect that.
The 'gen': false directive is omitted as implementation detail.
The 'success-response' directive is omitted as well for now, even
though it's not an implementation detail, because it's not used by
QMP.
* Events carry a single data value.
Implicit type definition and empty object type use, just like for
commands.
The value is of object type, but the introspection schema doesn't
reflect that.
* Types not used by commands or events are omitted.
Indirect use counts as use.
* Optional members have a default, which can only be null right now
Instead of a mandatory "optional" flag, we have an optional default.
No default means mandatory, default null means optional without
default value. Non-null is available for optional with default
(possible future extension).
* Clients should *not* look up types by name, because type names are
not ABI. Look up the command or event you're interested in, then
follow the references.
TODO Should we hide the type names to eliminate the temptation?
New generator scripts/qapi-introspect.py computes an introspection
value for its input, and generates a C variable holding it.
It can generate awfully long lines. Marked TODO.
A new test-qmp-input-visitor test case feeds its result for both
tests/qapi-schema/qapi-schema-test.json and qapi-schema.json to a
QmpInputVisitor to verify it actually conforms to the schema.
New QMP command query-qmp-schema takes its return value from that
variable. Its reply is some 85KiBytes for me right now.
If this turns out to be too much, we have a couple of options:
* We can use shorter names in the JSON. Not the QMP style.
* Optionally return the sub-schema for commands and events given as
arguments.
Right now qmp_query_schema() sends the string literal computed by
qmp-introspect.py. To compute sub-schema at run time, we'd have to
duplicate parts of qapi-introspect.py in C. Unattractive.
* Let clients cache the output of query-qmp-schema.
It changes only on QEMU upgrades, i.e. rarely. Provide a command
query-qmp-schema-hash. Clients can have a cache indexed by hash,
and re-query the schema only when they don't have it cached. Even
simpler: put the hash in the QMP greeting.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
2015-09-16 14:06:28 +03:00
|
|
|
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.
|
|
|
|
|
2016-05-10 10:36:39 +03:00
|
|
|
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",
|
2016-10-07 18:05:04 +03:00
|
|
|
"arguments": { "driver": "raw",
|
|
|
|
"node-name": "new_node",
|
|
|
|
"file": { "driver": "file",
|
|
|
|
"filename": "test.raw" } } }
|
2016-05-10 10:36:39 +03:00
|
|
|
<- { "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": {} }
|
|
|
|
|
2014-08-25 15:19:57 +04:00
|
|
|
trace-event-set-state
|
|
|
|
---------------------
|
|
|
|
|
|
|
|
Set the state of events.
|
|
|
|
|
2016-07-11 13:53:57 +03:00
|
|
|
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.
|
|
|
|
|
2014-08-25 15:19:57 +04:00
|
|
|
Example:
|
|
|
|
|
|
|
|
-> { "execute": "trace-event-set-state", "arguments": { "name": "qemu_memalign", "enable": "true" } }
|
|
|
|
<- { "return": {} }
|
2016-09-12 12:19:12 +03:00
|
|
|
|
arm: qmp: add query-gic-capabilities interface
This patch add "query-gic-capabilities" but does not implement it. The
command is ARM-only. The command will return a list of GICCapability
structs that describes all GIC versions that current QEMU and system
support.
Libvirt is possibly the first consumer of this new command.
Before this patch, a libvirt user can successfully configure all kinds
of GIC devices for ARM guests, no matter whether current QEMU/kernel
supports them. If the specified GIC version/type is not supported, the
user will get an ambiguous "QEMU boot failure" error when trying to start
the VM. This is not user-friendly.
With this patch, libvirt should be able to query which type (and which
version) of GIC device is supported. Using this information, libvirt
can warn the user during configuration of guests when specified GIC
device type is not supported. Or better, we can just list those versions
that we support, and filter out the unsupported ones.
For example, if we got the query result:
{"return": [{"emulated": false, "version": 3, "kernel": true},
{"emulated": true, "version": 2, "kernel": false}]}
then it means that we support emulated GIC version 2 using:
qemu-system-aarch64 -M virt,accel=tcg,gic-version=2 ...
or KVM-accelerated GIC version 3 using:
qemu-system-aarch64 -M virt,accel=kvm,gic-version=3 ...
If we specify other explicit GIC versions rather than the above, QEMU
will not be able to boot.
The community is working on a more generic way to query these kinds of
information about valid values of machine properties. However, due to
the importance of supporting this specific use case, weecided to first
implement this ad-hoc one; then when the generic method is ready, we
can move on to that one smoothly.
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 1458788142-17509-2-git-send-email-peterx@redhat.com
[PMM: tweaked commit message a bit; monitor.o is CONFIG_SOFTMMU only]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-03-30 19:27:24 +03:00
|
|
|
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 } ] }
|
|
|
|
|
2016-06-10 03:59:06 +03:00
|
|
|
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": [
|
2016-06-30 11:17:54 +03:00
|
|
|
{ "props": { "core-id": 8 }, "type": "POWER8-spapr-cpu-core",
|
2016-06-10 03:59:06 +03:00
|
|
|
"vcpus-count": 1 },
|
2016-06-30 11:17:54 +03:00
|
|
|
{ "props": { "core-id": 0 }, "type": "POWER8-spapr-cpu-core",
|
2016-06-10 03:59:06 +03:00
|
|
|
"vcpus-count": 1, "qom-path": "/machine/unattached/device[0]"}
|
|
|
|
]}'
|
pc: Implement query-hotpluggable-cpus callback
it returns a list of present/possible to hotplug CPU
objects with a list of properties to use with
device_add.
in PC case returned list would looks like:
-> { "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}
}
]}
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-06-22 12:11:42 +03:00
|
|
|
|
|
|
|
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}
|
|
|
|
}
|
|
|
|
]}
|