docs/qmp-commands.txt

   1                         QMP Supported Commands
   2                         ----------------------
   3
   4 This document describes all commands currently supported by QMP.
   5
   6 Most of the time their usage is exactly the same as in the user Monitor, this
   7 means that any other document which also describe commands (the manpage,
   8 QEMU's manual, etc) can and should be consulted.
   9
  10 QMP has two types of commands: regular and query commands. Regular commands
  11 usually change the Virtual Machine's state someway, while query commands just
  12 return information. The sections below are divided accordingly.
  13
  14 It's important to observe that all communication examples are formatted in
  15 a reader-friendly way, so that they're easier to understand. However, in real
  16 protocol usage, they're emitted as a single line.
  17
  18 Also, the following notation is used to denote data flow:
  19
  20 -> data issued by the Client
  21 <- Server data response
  22
  23 Please, refer to the QMP specification (docs/qmp-spec.txt) for detailed
  24 information on the Server command and response formats.
  25
  26 NOTE: This document is temporary and will be replaced soon.
  27
  28 1. Stability Considerations
  29 ===========================
  30
  31 The current QMP command set (described in this file) may be useful for a
  32 number of use cases, however it's limited and several commands have bad
  33 defined semantics, specially with regard to command completion.
  34
  35 These problems are going to be solved incrementally in the next QEMU releases
  36 and we're going to establish a deprecation policy for badly defined commands.
  37
  38 If you're planning to adopt QMP, please observe the following:
  39
  40     1. The deprecation policy will take effect and be documented soon, please
  41        check the documentation of each used command as soon as a new release of
  42        QEMU is available
  43
  44     2. DO NOT rely on anything which is not explicit documented
  45
  46     3. Errors, in special, are not documented. Applications should NOT check
  47        for specific errors classes or data (it's strongly recommended to only
  48        check for the "error" key)
  49
  50 2. Regular Commands
  51 ===================
  52
  53 Server's responses in the examples below are always a success response, please
  54 refer to the QMP specification for more details on error responses.
  55
  56 eject
  57 -----
  58
  59 Eject a removable medium.
  60
  61 Arguments:
  62
  63 - "force": force ejection (json-bool, optional)
  64 - "device": block device name (deprecated, use @id instead)
  65             (json-string, optional)
  66 - "id": the name or QOM path of the guest device (json-string, optional)
  67
  68 Example:
  69
  70 -> { "execute": "eject", "arguments": { "id": "ide0-1-0" } }
  71 <- { "return": {} }
  72
  73 Note: The "force" argument defaults to false.
  74
  75 device_add
  76 ----------
  77
  78 Add a device.
  79
  80 Arguments:
  81
  82 - "driver": the name of the new device's driver (json-string)
  83 - "bus": the device's parent bus (device tree path, json-string, optional)
  84 - "id": the device's ID, must be unique (json-string)
  85 - device properties
  86
  87 Example:
  88
  89 -> { "execute": "device_add", "arguments": { "driver": "e1000", "id": "net1" } }
  90 <- { "return": {} }
  91
  92 Notes:
  93
  94 (1) For detailed information about this command, please refer to the
  95     'docs/qdev-device-use.txt' file.
  96
  97 (2) It's possible to list device properties by running QEMU with the
  98     "-device DEVICE,\?" command-line argument, where DEVICE is the device's name
  99
 100 cpu
 101 ---
 102
 103 Set the default CPU.
 104
 105 Arguments:
 106
 107 - "index": the CPU's index (json-int)
 108
 109 Example:
 110
 111 -> { "execute": "cpu", "arguments": { "index": 0 } }
 112 <- { "return": {} }
 113
 114 Note: CPUs' indexes are obtained with the 'query-cpus' command.
 115
 116 xen-load-devices-state
 117 ----------------------
 118
 119 Load the state of all devices from file. The RAM and the block devices
 120 of the VM are not loaded by this command.
 121
 122 Arguments:
 123
 124 - "filename": the file to load the state of the devices from as binary
 125 data. See xen-save-devices-state.txt for a description of the binary
 126 format.
 127
 128 Example:
 129
 130 -> { "execute": "xen-load-devices-state",
 131      "arguments": { "filename": "/tmp/resume" } }
 132 <- { "return": {} }
 133
 134 migrate-set-cache-size
 135 ----------------------
 136
 137 Set cache size to be used by XBZRLE migration, the cache size will be rounded
 138 down to the nearest power of 2
 139
 140 Arguments:
 141
 142 - "value": cache size in bytes (json-int)
 143
 144 Example:
 145
 146 -> { "execute": "migrate-set-cache-size", "arguments": { "value": 536870912 } }
 147 <- { "return": {} }
 148
 149 x-colo-lost-heartbeat
 150 --------------------
 151
 152 Tell COLO that heartbeat is lost, a failover or takeover is needed.
 153
 154 Example:
 155
 156 -> { "execute": "x-colo-lost-heartbeat" }
 157 <- { "return": {} }
 158
 159 query-dump
 160 ----------
 161
 162 Query background dump status.
 163
 164 Arguments: None.
 165
 166 Example:
 167
 168 -> { "execute": "query-dump" }
 169 <- { "return": { "status": "active", "completed": 1024000,
 170                  "total": 2048000 } }
 171
 172 block-stream
 173 ------------
 174
 175 Copy data from a backing file into a block device.
 176
 177 Arguments:
 178
 179 - "job-id": Identifier for the newly-created block job. If omitted,
 180             the device name will be used. (json-string, optional)
 181 - "device": The device name or node-name of a root node (json-string)
 182 - "base": The file name of the backing image above which copying starts.
 183           It cannot be set if 'base-node' is also set (json-string, optional)
 184 - "base-node": the node name of the backing image above which copying starts.
 185                It cannot be set if 'base' is also set.
 186                (json-string, optional) (Since 2.8)
 187 - "backing-file": The backing file string to write into the active layer. This
 188                   filename is not validated.
 189
 190                   If a pathname string is such that it cannot be resolved by
 191                   QEMU, that means that subsequent QMP or HMP commands must use
 192                   node-names for the image in question, as filename lookup
 193                   methods will fail.
 194
 195                   If not specified, QEMU will automatically determine the
 196                   backing file string to use, or error out if there is no
 197                   obvious choice.  Care should be taken when specifying the
 198                   string, to specify a valid filename or protocol.
 199                   (json-string, optional) (Since 2.1)
 200 - "speed":  the maximum speed, in bytes per second (json-int, optional)
 201 - "on-error": the action to take on an error (default 'report').  'stop' and
 202               'enospc' can only be used if the block device supports io-status.
 203               (json-string, optional) (Since 2.1)
 204
 205 Example:
 206
 207 -> { "execute": "block-stream", "arguments": { "device": "virtio0",
 208                                                "base": "/tmp/master.qcow2" } }
 209 <- { "return": {} }
 210
 211 blockdev-snapshot-internal-sync
 212 -------------------------------
 213
 214 Synchronously take an internal snapshot of a block device when the format of
 215 image used supports it.  If the name is an empty string, or a snapshot with
 216 name already exists, the operation will fail.
 217
 218 Arguments:
 219
 220 - "device": the device name or node-name of a root node to snapshot
 221             (json-string)
 222 - "name": name of the new snapshot (json-string)
 223
 224 Example:
 225
 226 -> { "execute": "blockdev-snapshot-internal-sync",
 227                 "arguments": { "device": "ide-hd0",
 228                                "name": "snapshot0" }
 229    }
 230 <- { "return": {} }
 231
 232 blockdev-snapshot-delete-internal-sync
 233 --------------------------------------
 234
 235 Synchronously delete an internal snapshot of a block device when the format of
 236 image used supports it.  The snapshot is identified by name or id or both.  One
 237 of name or id is required.  If the snapshot is not found, the operation will
 238 fail.
 239
 240 Arguments:
 241
 242 - "device": the device name or node-name of a root node (json-string)
 243 - "id": ID of the snapshot (json-string, optional)
 244 - "name": name of the snapshot (json-string, optional)
 245
 246 Example:
 247
 248 -> { "execute": "blockdev-snapshot-delete-internal-sync",
 249                 "arguments": { "device": "ide-hd0",
 250                                "name": "snapshot0" }
 251    }
 252 <- { "return": {
 253                    "id": "1",
 254                    "name": "snapshot0",
 255                    "vm-state-size": 0,
 256                    "date-sec": 1000012,
 257                    "date-nsec": 10,
 258                    "vm-clock-sec": 100,
 259                    "vm-clock-nsec": 20
 260      }
 261    }
 262
 263 blockdev-mirror
 264 ------------
 265
 266 Start mirroring a block device's writes to another block device. target
 267 specifies the target of mirror operation.
 268
 269 Arguments:
 270
 271 - "job-id": Identifier for the newly-created block job. If omitted,
 272             the device name will be used. (json-string, optional)
 273 - "device": The device name or node-name of a root node whose writes should be
 274             mirrored (json-string)
 275 - "target": device name to mirror to (json-string)
 276 - "replaces": the block driver node name to replace when finished
 277               (json-string, optional)
 278 - "speed": maximum speed of the streaming job, in bytes per second
 279   (json-int)
 280 - "granularity": granularity of the dirty bitmap, in bytes (json-int, optional)
 281 - "buf_size": maximum amount of data in flight from source to target, in bytes
 282   (json-int, default 10M)
 283 - "sync": what parts of the disk image should be copied to the destination;
 284   possibilities include "full" for all the disk, "top" for only the sectors
 285   allocated in the topmost image, or "none" to only replicate new I/O
 286   (MirrorSyncMode).
 287 - "on-source-error": the action to take on an error on the source
 288   (BlockdevOnError, default 'report')
 289 - "on-target-error": the action to take on an error on the target
 290   (BlockdevOnError, default 'report')
 291
 292 The default value of the granularity is the image cluster size clamped
 293 between 4096 and 65536, if the image format defines one.  If the format
 294 does not define a cluster size, the default value of the granularity
 295 is 65536.
 296
 297 Example:
 298
 299 -> { "execute": "blockdev-mirror", "arguments": { "device": "ide-hd0",
 300                                                   "target": "target0",
 301                                                   "sync": "full" } }
 302 <- { "return": {} }
 303
 304 qmp_capabilities
 305 ----------------
 306
 307 Enable QMP capabilities.
 308
 309 Arguments: None.
 310
 311 Example:
 312
 313 -> { "execute": "qmp_capabilities" }
 314 <- { "return": {} }
 315
 316 Note: This command must be issued before issuing any other command.
 317
 318 3. Query Commands
 319 =================
 320
 321
 322 query-version
 323 -------------
 324
 325 Show QEMU version.
 326
 327 Return a json-object with the following information:
 328
 329 - "qemu": A json-object containing three integer values:
 330     - "major": QEMU's major version (json-int)
 331     - "minor": QEMU's minor version (json-int)
 332     - "micro": QEMU's micro version (json-int)
 333 - "package": package's version (json-string)
 334
 335 Example:
 336
 337 -> { "execute": "query-version" }
 338 <- {
 339       "return":{
 340          "qemu":{
 341             "major":0,
 342             "minor":11,
 343             "micro":5
 344          },
 345          "package":""
 346       }
 347    }
 348
 349 query-commands
 350 --------------
 351
 352 List QMP available commands.
 353
 354 Each command is represented by a json-object, the returned value is a json-array
 355 of all commands.
 356
 357 Each json-object contain:
 358
 359 - "name": command's name (json-string)
 360
 361 Example:
 362
 363 -> { "execute": "query-commands" }
 364 <- {
 365       "return":[
 366          {
 367             "name":"query-balloon"
 368          },
 369          {
 370             "name":"system_powerdown"
 371          }
 372       ]
 373    }
 374
 375 Note: This example has been shortened as the real response is too long.
 376
 377 query-qmp-schema
 378 ----------------
 379
 380 Return the QMP wire schema.  The returned value is a json-array of
 381 named schema entities.  Entities are commands, events and various
 382 types.  See docs/qapi-code-gen.txt for information on their structure
 383 and intended use.
 384
 385 blockdev-add
 386 ------------
 387
 388 Add a block device.
 389
 390 This command is still a work in progress.  It doesn't support all
 391 block drivers among other things.  Stay away from it unless you want
 392 to help with its development.
 393
 394 For the arguments, see the QAPI schema documentation of BlockdevOptions.
 395
 396 Example (1):
 397
 398 -> { "execute": "blockdev-add",
 399     "arguments": { "driver": "qcow2",
 400                    "file": { "driver": "file",
 401                              "filename": "test.qcow2" } } }
 402 <- { "return": {} }
 403
 404 Example (2):
 405
 406 -> { "execute": "blockdev-add",
 407      "arguments": {
 408          "driver": "qcow2",
 409          "node-name": "my_disk",
 410          "discard": "unmap",
 411          "cache": {
 412              "direct": true,
 413              "writeback": true
 414          },
 415          "file": {
 416              "driver": "file",
 417              "filename": "/tmp/test.qcow2"
 418          },
 419          "backing": {
 420              "driver": "raw",
 421              "file": {
 422                  "driver": "file",
 423                  "filename": "/dev/fdset/4"
 424              }
 425          }
 426        }
 427      }
 428
 429 <- { "return": {} }
 430
 431 x-blockdev-del
 432 ------------
 433 Since 2.5
 434
 435 Deletes a block device that has been added using blockdev-add.
 436 The command will fail if the node is attached to a device or is
 437 otherwise being used.
 438
 439 This command is still a work in progress and is considered
 440 experimental. Stay away from it unless you want to help with its
 441 development.
 442
 443 Arguments:
 444
 445 - "node-name": Name of the graph node to delete (json-string)
 446
 447 Example:
 448
 449 -> { "execute": "blockdev-add",
 450      "arguments": {
 451          "driver": "qcow2",
 452          "node-name": "node0",
 453          "file": {
 454              "driver": "file",
 455              "filename": "test.qcow2"
 456          }
 457      }
 458    }
 459
 460 <- { "return": {} }
 461
 462 -> { "execute": "x-blockdev-del",
 463      "arguments": { "node-name": "node0" }
 464    }
 465 <- { "return": {} }
 466
 467 blockdev-open-tray
 468 ------------------
 469
 470 Opens a block device's tray. If there is a block driver state tree inserted as a
 471 medium, it will become inaccessible to the guest (but it will remain associated
 472 to the block device, so closing the tray will make it accessible again).
 473
 474 If the tray was already open before, this will be a no-op.
 475
 476 Once the tray opens, a DEVICE_TRAY_MOVED event is emitted. There are cases in
 477 which no such event will be generated, these include:
 478 - if the guest has locked the tray, @force is false and the guest does not
 479   respond to the eject request
 480 - if the BlockBackend denoted by @device does not have a guest device attached
 481   to it
 482 - if the guest device does not have an actual tray and is empty, for instance
 483   for floppy disk drives
 484
 485 Arguments:
 486
 487 - "device": block device name (deprecated, use @id instead)
 488             (json-string, optional)
 489 - "id": the name or QOM path of the guest device (json-string, optional)
 490 - "force": if false (the default), an eject request will be sent to the guest if
 491            it has locked the tray (and the tray will not be opened immediately);
 492            if true, the tray will be opened regardless of whether it is locked
 493            (json-bool, optional)
 494
 495 Example:
 496
 497 -> { "execute": "blockdev-open-tray",
 498      "arguments": { "id": "ide0-1-0" } }
 499
 500 <- { "timestamp": { "seconds": 1418751016,
 501                     "microseconds": 716996 },
 502      "event": "DEVICE_TRAY_MOVED",
 503      "data": { "device": "ide1-cd0",
 504                "id": "ide0-1-0",
 505                "tray-open": true } }
 506
 507 <- { "return": {} }
 508
 509 blockdev-close-tray
 510 -------------------
 511
 512 Closes a block device's tray. If there is a block driver state tree associated
 513 with the block device (which is currently ejected), that tree will be loaded as
 514 the medium.
 515
 516 If the tray was already closed before, this will be a no-op.
 517
 518 Arguments:
 519
 520 - "device": block device name (deprecated, use @id instead)
 521             (json-string, optional)
 522 - "id": the name or QOM path of the guest device (json-string, optional)
 523
 524 Example:
 525
 526 -> { "execute": "blockdev-close-tray",
 527      "arguments": { "id": "ide0-1-0" } }
 528
 529 <- { "timestamp": { "seconds": 1418751345,
 530                     "microseconds": 272147 },
 531      "event": "DEVICE_TRAY_MOVED",
 532      "data": { "device": "ide1-cd0",
 533                "id": "ide0-1-0",
 534                "tray-open": false } }
 535
 536 <- { "return": {} }
 537
 538 x-blockdev-remove-medium
 539 ------------------------
 540
 541 Removes a medium (a block driver state tree) from a block device. That block
 542 device's tray must currently be open (unless there is no attached guest device).
 543
 544 If the tray is open and there is no medium inserted, this will be a no-op.
 545
 546 This command is still a work in progress and is considered experimental.
 547 Stay away from it unless you want to help with its development.
 548
 549 Arguments:
 550
 551 - "device": block device name (deprecated, use @id instead)
 552             (json-string, optional)
 553 - "id": the name or QOM path of the guest device (json-string, optional)
 554
 555 Example:
 556
 557 -> { "execute": "x-blockdev-remove-medium",
 558      "arguments": { "id": "ide0-1-0" } }
 559
 560 <- { "error": { "class": "GenericError",
 561                 "desc": "Tray of device 'ide0-1-0' is not open" } }
 562
 563 -> { "execute": "blockdev-open-tray",
 564      "arguments": { "id": "ide0-1-0" } }
 565
 566 <- { "timestamp": { "seconds": 1418751627,
 567                     "microseconds": 549958 },
 568      "event": "DEVICE_TRAY_MOVED",
 569      "data": { "device": "ide1-cd0",
 570                "id": "ide0-1-0",
 571                "tray-open": true } }
 572
 573 <- { "return": {} }
 574
 575 -> { "execute": "x-blockdev-remove-medium",
 576      "arguments": { "device": "ide0-1-0" } }
 577
 578 <- { "return": {} }
 579
 580 x-blockdev-insert-medium
 581 ------------------------
 582
 583 Inserts a medium (a block driver state tree) into a block device. That block
 584 device's tray must currently be open (unless there is no attached guest device)
 585 and there must be no medium inserted already.
 586
 587 This command is still a work in progress and is considered experimental.
 588 Stay away from it unless you want to help with its development.
 589
 590 Arguments:
 591
 592 - "device": block device name (deprecated, use @id instead)
 593             (json-string, optional)
 594 - "id": the name or QOM path of the guest device (json-string, optional)
 595 - "node-name": root node of the BDS tree to insert into the block device
 596
 597 Example:
 598
 599 -> { "execute": "blockdev-add",
 600      "arguments": { { "node-name": "node0",
 601                       "driver": "raw",
 602                       "file": { "driver": "file",
 603                                 "filename": "fedora.iso" } } }
 604
 605 <- { "return": {} }
 606
 607 -> { "execute": "x-blockdev-insert-medium",
 608      "arguments": { "id": "ide0-1-0",
 609                     "node-name": "node0" } }
 610
 611 <- { "return": {} }
 612
 613 x-blockdev-change
 614 -----------------
 615
 616 Dynamically reconfigure the block driver state graph. It can be used
 617 to add, remove, insert or replace a graph node. Currently only the
 618 Quorum driver implements this feature to add or remove its child. This
 619 is useful to fix a broken quorum child.
 620
 621 If @node is specified, it will be inserted under @parent. @child
 622 may not be specified in this case. If both @parent and @child are
 623 specified but @node is not, @child will be detached from @parent.
 624
 625 Arguments:
 626 - "parent": the id or name of the parent node (json-string)
 627 - "child": the name of a child under the given parent node (json-string, optional)
 628 - "node": the name of the node that will be added (json-string, optional)
 629
 630 Note: this command is experimental, and not a stable API. It doesn't
 631 support all kinds of operations, all kinds of children, nor all block
 632 drivers.
 633
 634 Warning: The data in a new quorum child MUST be consistent with that of
 635 the rest of the array.
 636
 637 Example:
 638
 639 Add a new node to a quorum
 640 -> { "execute": "blockdev-add",
 641      "arguments": { "driver": "raw",
 642                     "node-name": "new_node",
 643                     "file": { "driver": "file",
 644                               "filename": "test.raw" } } }
 645 <- { "return": {} }
 646 -> { "execute": "x-blockdev-change",
 647      "arguments": { "parent": "disk1",
 648                     "node": "new_node" } }
 649 <- { "return": {} }
 650
 651 Delete a quorum's node
 652 -> { "execute": "x-blockdev-change",
 653      "arguments": { "parent": "disk1",
 654                     "child": "children.1" } }
 655 <- { "return": {} }
 656
 657 blockdev-change-medium
 658 ----------------------
 659
 660 Changes the medium inserted into a block device by ejecting the current medium
 661 and loading a new image file which is inserted as the new medium.
 662
 663 Arguments:
 664
 665 - "device": block device name (deprecated, use @id instead)
 666             (json-string, optional)
 667 - "id": the name or QOM path of the guest device (json-string, optional)
 668 - "filename": filename of the new image (json-string)
 669 - "format": format of the new image (json-string, optional)
 670 - "read-only-mode": new read-only mode (json-string, optional)
 671           - Possible values: "retain" (default), "read-only", "read-write"
 672
 673 Examples:
 674
 675 1. Change a removable medium
 676
 677 -> { "execute": "blockdev-change-medium",
 678              "arguments": { "id": "ide0-1-0",
 679                             "filename": "/srv/images/Fedora-12-x86_64-DVD.iso",
 680                             "format": "raw" } }
 681 <- { "return": {} }
 682
 683 2. Load a read-only medium into a writable drive
 684
 685 -> { "execute": "blockdev-change-medium",
 686              "arguments": { "id": "floppyA",
 687                             "filename": "/srv/images/ro.img",
 688                             "format": "raw",
 689                             "read-only-mode": "retain" } }
 690
 691 <- { "error":
 692      { "class": "GenericError",
 693        "desc": "Could not open '/srv/images/ro.img': Permission denied" } }
 694
 695 -> { "execute": "blockdev-change-medium",
 696              "arguments": { "id": "floppyA",
 697                             "filename": "/srv/images/ro.img",
 698                             "format": "raw",
 699                             "read-only-mode": "read-only" } }
 700
 701 <- { "return": {} }
 702
 703 trace-event-get-state
 704 ---------------------
 705
 706 Query the state of events.
 707
 708 Arguments:
 709
 710 - "name": Event name pattern (json-string).
 711 - "vcpu": The vCPU to query, any vCPU by default (json-int, optional).
 712
 713 An event is returned if:
 714 - its name matches the "name" pattern, and
 715 - if "vcpu" is given, the event has the "vcpu" property.
 716
 717 Therefore, if "vcpu" is given, the operation will only match per-vCPU events,
 718 returning their state on the specified vCPU. Special case: if "name" is an exact
 719 match, "vcpu" is given and the event does not have the "vcpu" property, an error
 720 is returned.
 721
 722 Example:
 723
 724 -> { "execute": "trace-event-get-state", "arguments": { "name": "qemu_memalign" } }
 725 <- { "return": [ { "name": "qemu_memalign", "state": "disabled" } ] }
 726
 727 trace-event-set-state
 728 ---------------------
 729
 730 Set the state of events.
 731
 732 Arguments:
 733
 734 - "name": Event name pattern (json-string).
 735 - "enable": Whether to enable or disable the event (json-bool).
 736 - "ignore-unavailable": Whether to ignore errors for events that cannot be
 737   changed (json-bool, optional).
 738 - "vcpu": The vCPU to act upon, all vCPUs by default (json-int, optional).
 739
 740 An event's state is modified if:
 741 - its name matches the "name" pattern, and
 742 - if "vcpu" is given, the event has the "vcpu" property.
 743
 744 Therefore, if "vcpu" is given, the operation will only match per-vCPU events,
 745 setting their state on the specified vCPU. Special case: if "name" is an exact
 746 match, "vcpu" is given and the event does not have the "vcpu" property, an error
 747 is returned.
 748
 749 Example:
 750
 751 -> { "execute": "trace-event-set-state", "arguments": { "name": "qemu_memalign", "enable": "true" } }
 752 <- { "return": {} }
 753
 754 block-set-write-threshold
 755 ------------
 756
 757 Change the write threshold for a block drive. The threshold is an offset,
 758 thus must be non-negative. Default is no write threshold.
 759 Setting the threshold to zero disables it.
 760
 761 Arguments:
 762
 763 - "node-name": the node name in the block driver state graph (json-string)
 764 - "write-threshold": the write threshold in bytes (json-int)
 765
 766 Example:
 767
 768 -> { "execute": "block-set-write-threshold",
 769   "arguments": { "node-name": "mydev",
 770                  "write-threshold": 17179869184 } }
 771 <- { "return": {} }
 772
 773 Show rocker switch
 774 ------------------
 775
 776 Arguments:
 777
 778 - "name": switch name
 779
 780 Example:
 781
 782 -> { "execute": "query-rocker", "arguments": { "name": "sw1" } }
 783 <- { "return": {"name": "sw1", "ports": 2, "id": 1327446905938}}
 784
 785 Show rocker switch ports
 786 ------------------------
 787
 788 Arguments:
 789
 790 - "name": switch name
 791
 792 Example:
 793
 794 -> { "execute": "query-rocker-ports", "arguments": { "name": "sw1" } }
 795 <- { "return": [ {"duplex": "full", "enabled": true, "name": "sw1.1",
 796                   "autoneg": "off", "link-up": true, "speed": 10000},
 797                  {"duplex": "full", "enabled": true, "name": "sw1.2",
 798                   "autoneg": "off", "link-up": true, "speed": 10000}
 799    ]}
 800
 801 Show rocker switch OF-DPA flow tables
 802 -------------------------------------
 803
 804 Arguments:
 805
 806 - "name": switch name
 807 - "tbl-id": (optional) flow table ID
 808
 809 Example:
 810
 811 -> { "execute": "query-rocker-of-dpa-flows", "arguments": { "name": "sw1" } }
 812 <- { "return": [ {"key": {"in-pport": 0, "priority": 1, "tbl-id": 0},
 813                   "hits": 138,
 814                   "cookie": 0,
 815                   "action": {"goto-tbl": 10},
 816                   "mask": {"in-pport": 4294901760}
 817                  },
 818                  {...more...},
 819    ]}
 820
 821 Show rocker OF-DPA group tables
 822 -------------------------------
 823
 824 Arguments:
 825
 826 - "name": switch name
 827 - "type": (optional) group type
 828
 829 Example:
 830
 831 -> { "execute": "query-rocker-of-dpa-groups", "arguments": { "name": "sw1" } }
 832 <- { "return": [ {"type": 0, "out-pport": 2, "pport": 2, "vlan-id": 3841,
 833                   "pop-vlan": 1, "id": 251723778},
 834                  {"type": 0, "out-pport": 0, "pport": 0, "vlan-id": 3841,
 835                   "pop-vlan": 1, "id": 251723776},
 836                  {"type": 0, "out-pport": 1, "pport": 1, "vlan-id": 3840,
 837                   "pop-vlan": 1, "id": 251658241},
 838                  {"type": 0, "out-pport": 0, "pport": 0, "vlan-id": 3840,
 839                   "pop-vlan": 1, "id": 251658240}
 840    ]}
 841
 842 query-gic-capabilities
 843 ---------------
 844
 845 Return a list of GICCapability objects, describing supported GIC
 846 (Generic Interrupt Controller) versions.
 847
 848 Arguments: None
 849
 850 Example:
 851
 852 -> { "execute": "query-gic-capabilities" }
 853 <- { "return": [{ "version": 2, "emulated": true, "kernel": false },
 854                 { "version": 3, "emulated": false, "kernel": true } ] }
 855
 856 Show existing/possible CPUs
 857 ---------------------------
 858
 859 Arguments: None.
 860
 861 Example for pseries machine type started with
 862 -smp 2,cores=2,maxcpus=4 -cpu POWER8:
 863
 864 -> { "execute": "query-hotpluggable-cpus" }
 865 <- {"return": [
 866      { "props": { "core-id": 8 }, "type": "POWER8-spapr-cpu-core",
 867        "vcpus-count": 1 },
 868      { "props": { "core-id": 0 }, "type": "POWER8-spapr-cpu-core",
 869        "vcpus-count": 1, "qom-path": "/machine/unattached/device[0]"}
 870    ]}'
 871
 872 Example for pc machine type started with
 873 -smp 1,maxcpus=2:
 874     -> { "execute": "query-hotpluggable-cpus" }
 875     <- {"return": [
 876          {
 877             "type": "qemu64-x86_64-cpu", "vcpus-count": 1,
 878             "props": {"core-id": 0, "socket-id": 1, "thread-id": 0}
 879          },
 880          {
 881             "qom-path": "/machine/unattached/device[0]",
 882             "type": "qemu64-x86_64-cpu", "vcpus-count": 1,
 883             "props": {"core-id": 0, "socket-id": 0, "thread-id": 0}
 884          }
 885        ]}