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 blockdev-snapshot-internal-sync
 173 -------------------------------
 174
 175 Synchronously take an internal snapshot of a block device when the format of
 176 image used supports it.  If the name is an empty string, or a snapshot with
 177 name already exists, the operation will fail.
 178
 179 Arguments:
 180
 181 - "device": the device name or node-name of a root node to snapshot
 182             (json-string)
 183 - "name": name of the new snapshot (json-string)
 184
 185 Example:
 186
 187 -> { "execute": "blockdev-snapshot-internal-sync",
 188                 "arguments": { "device": "ide-hd0",
 189                                "name": "snapshot0" }
 190    }
 191 <- { "return": {} }
 192
 193 blockdev-snapshot-delete-internal-sync
 194 --------------------------------------
 195
 196 Synchronously delete an internal snapshot of a block device when the format of
 197 image used supports it.  The snapshot is identified by name or id or both.  One
 198 of name or id is required.  If the snapshot is not found, the operation will
 199 fail.
 200
 201 Arguments:
 202
 203 - "device": the device name or node-name of a root node (json-string)
 204 - "id": ID of the snapshot (json-string, optional)
 205 - "name": name of the snapshot (json-string, optional)
 206
 207 Example:
 208
 209 -> { "execute": "blockdev-snapshot-delete-internal-sync",
 210                 "arguments": { "device": "ide-hd0",
 211                                "name": "snapshot0" }
 212    }
 213 <- { "return": {
 214                    "id": "1",
 215                    "name": "snapshot0",
 216                    "vm-state-size": 0,
 217                    "date-sec": 1000012,
 218                    "date-nsec": 10,
 219                    "vm-clock-sec": 100,
 220                    "vm-clock-nsec": 20
 221      }
 222    }
 223
 224 blockdev-mirror
 225 ------------
 226
 227 Start mirroring a block device's writes to another block device. target
 228 specifies the target of mirror operation.
 229
 230 Arguments:
 231
 232 - "job-id": Identifier for the newly-created block job. If omitted,
 233             the device name will be used. (json-string, optional)
 234 - "device": The device name or node-name of a root node whose writes should be
 235             mirrored (json-string)
 236 - "target": device name to mirror to (json-string)
 237 - "replaces": the block driver node name to replace when finished
 238               (json-string, optional)
 239 - "speed": maximum speed of the streaming job, in bytes per second
 240   (json-int)
 241 - "granularity": granularity of the dirty bitmap, in bytes (json-int, optional)
 242 - "buf_size": maximum amount of data in flight from source to target, in bytes
 243   (json-int, default 10M)
 244 - "sync": what parts of the disk image should be copied to the destination;
 245   possibilities include "full" for all the disk, "top" for only the sectors
 246   allocated in the topmost image, or "none" to only replicate new I/O
 247   (MirrorSyncMode).
 248 - "on-source-error": the action to take on an error on the source
 249   (BlockdevOnError, default 'report')
 250 - "on-target-error": the action to take on an error on the target
 251   (BlockdevOnError, default 'report')
 252
 253 The default value of the granularity is the image cluster size clamped
 254 between 4096 and 65536, if the image format defines one.  If the format
 255 does not define a cluster size, the default value of the granularity
 256 is 65536.
 257
 258 Example:
 259
 260 -> { "execute": "blockdev-mirror", "arguments": { "device": "ide-hd0",
 261                                                   "target": "target0",
 262                                                   "sync": "full" } }
 263 <- { "return": {} }
 264
 265 qmp_capabilities
 266 ----------------
 267
 268 Enable QMP capabilities.
 269
 270 Arguments: None.
 271
 272 Example:
 273
 274 -> { "execute": "qmp_capabilities" }
 275 <- { "return": {} }
 276
 277 Note: This command must be issued before issuing any other command.
 278
 279 3. Query Commands
 280 =================
 281
 282
 283 query-version
 284 -------------
 285
 286 Show QEMU version.
 287
 288 Return a json-object with the following information:
 289
 290 - "qemu": A json-object containing three integer values:
 291     - "major": QEMU's major version (json-int)
 292     - "minor": QEMU's minor version (json-int)
 293     - "micro": QEMU's micro version (json-int)
 294 - "package": package's version (json-string)
 295
 296 Example:
 297
 298 -> { "execute": "query-version" }
 299 <- {
 300       "return":{
 301          "qemu":{
 302             "major":0,
 303             "minor":11,
 304             "micro":5
 305          },
 306          "package":""
 307       }
 308    }
 309
 310 query-commands
 311 --------------
 312
 313 List QMP available commands.
 314
 315 Each command is represented by a json-object, the returned value is a json-array
 316 of all commands.
 317
 318 Each json-object contain:
 319
 320 - "name": command's name (json-string)
 321
 322 Example:
 323
 324 -> { "execute": "query-commands" }
 325 <- {
 326       "return":[
 327          {
 328             "name":"query-balloon"
 329          },
 330          {
 331             "name":"system_powerdown"
 332          }
 333       ]
 334    }
 335
 336 Note: This example has been shortened as the real response is too long.
 337
 338 query-qmp-schema
 339 ----------------
 340
 341 Return the QMP wire schema.  The returned value is a json-array of
 342 named schema entities.  Entities are commands, events and various
 343 types.  See docs/qapi-code-gen.txt for information on their structure
 344 and intended use.
 345
 346 x-blockdev-del
 347 ------------
 348 Since 2.5
 349
 350 Deletes a block device that has been added using blockdev-add.
 351 The command will fail if the node is attached to a device or is
 352 otherwise being used.
 353
 354 This command is still a work in progress and is considered
 355 experimental. Stay away from it unless you want to help with its
 356 development.
 357
 358 Arguments:
 359
 360 - "node-name": Name of the graph node to delete (json-string)
 361
 362 Example:
 363
 364 -> { "execute": "blockdev-add",
 365      "arguments": {
 366          "driver": "qcow2",
 367          "node-name": "node0",
 368          "file": {
 369              "driver": "file",
 370              "filename": "test.qcow2"
 371          }
 372      }
 373    }
 374
 375 <- { "return": {} }
 376
 377 -> { "execute": "x-blockdev-del",
 378      "arguments": { "node-name": "node0" }
 379    }
 380 <- { "return": {} }
 381
 382 blockdev-open-tray
 383 ------------------
 384
 385 Opens a block device's tray. If there is a block driver state tree inserted as a
 386 medium, it will become inaccessible to the guest (but it will remain associated
 387 to the block device, so closing the tray will make it accessible again).
 388
 389 If the tray was already open before, this will be a no-op.
 390
 391 Once the tray opens, a DEVICE_TRAY_MOVED event is emitted. There are cases in
 392 which no such event will be generated, these include:
 393 - if the guest has locked the tray, @force is false and the guest does not
 394   respond to the eject request
 395 - if the BlockBackend denoted by @device does not have a guest device attached
 396   to it
 397 - if the guest device does not have an actual tray and is empty, for instance
 398   for floppy disk drives
 399
 400 Arguments:
 401
 402 - "device": block device name (deprecated, use @id instead)
 403             (json-string, optional)
 404 - "id": the name or QOM path of the guest device (json-string, optional)
 405 - "force": if false (the default), an eject request will be sent to the guest if
 406            it has locked the tray (and the tray will not be opened immediately);
 407            if true, the tray will be opened regardless of whether it is locked
 408            (json-bool, optional)
 409
 410 Example:
 411
 412 -> { "execute": "blockdev-open-tray",
 413      "arguments": { "id": "ide0-1-0" } }
 414
 415 <- { "timestamp": { "seconds": 1418751016,
 416                     "microseconds": 716996 },
 417      "event": "DEVICE_TRAY_MOVED",
 418      "data": { "device": "ide1-cd0",
 419                "id": "ide0-1-0",
 420                "tray-open": true } }
 421
 422 <- { "return": {} }
 423
 424 blockdev-close-tray
 425 -------------------
 426
 427 Closes a block device's tray. If there is a block driver state tree associated
 428 with the block device (which is currently ejected), that tree will be loaded as
 429 the medium.
 430
 431 If the tray was already closed before, this will be a no-op.
 432
 433 Arguments:
 434
 435 - "device": block device name (deprecated, use @id instead)
 436             (json-string, optional)
 437 - "id": the name or QOM path of the guest device (json-string, optional)
 438
 439 Example:
 440
 441 -> { "execute": "blockdev-close-tray",
 442      "arguments": { "id": "ide0-1-0" } }
 443
 444 <- { "timestamp": { "seconds": 1418751345,
 445                     "microseconds": 272147 },
 446      "event": "DEVICE_TRAY_MOVED",
 447      "data": { "device": "ide1-cd0",
 448                "id": "ide0-1-0",
 449                "tray-open": false } }
 450
 451 <- { "return": {} }
 452
 453 x-blockdev-remove-medium
 454 ------------------------
 455
 456 Removes a medium (a block driver state tree) from a block device. That block
 457 device's tray must currently be open (unless there is no attached guest device).
 458
 459 If the tray is open and there is no medium inserted, this will be a no-op.
 460
 461 This command is still a work in progress and is considered experimental.
 462 Stay away from it unless you want to help with its development.
 463
 464 Arguments:
 465
 466 - "device": block device name (deprecated, use @id instead)
 467             (json-string, optional)
 468 - "id": the name or QOM path of the guest device (json-string, optional)
 469
 470 Example:
 471
 472 -> { "execute": "x-blockdev-remove-medium",
 473      "arguments": { "id": "ide0-1-0" } }
 474
 475 <- { "error": { "class": "GenericError",
 476                 "desc": "Tray of device 'ide0-1-0' is not open" } }
 477
 478 -> { "execute": "blockdev-open-tray",
 479      "arguments": { "id": "ide0-1-0" } }
 480
 481 <- { "timestamp": { "seconds": 1418751627,
 482                     "microseconds": 549958 },
 483      "event": "DEVICE_TRAY_MOVED",
 484      "data": { "device": "ide1-cd0",
 485                "id": "ide0-1-0",
 486                "tray-open": true } }
 487
 488 <- { "return": {} }
 489
 490 -> { "execute": "x-blockdev-remove-medium",
 491      "arguments": { "device": "ide0-1-0" } }
 492
 493 <- { "return": {} }
 494
 495 x-blockdev-insert-medium
 496 ------------------------
 497
 498 Inserts a medium (a block driver state tree) into a block device. That block
 499 device's tray must currently be open (unless there is no attached guest device)
 500 and there must be no medium inserted already.
 501
 502 This command is still a work in progress and is considered experimental.
 503 Stay away from it unless you want to help with its development.
 504
 505 Arguments:
 506
 507 - "device": block device name (deprecated, use @id instead)
 508             (json-string, optional)
 509 - "id": the name or QOM path of the guest device (json-string, optional)
 510 - "node-name": root node of the BDS tree to insert into the block device
 511
 512 Example:
 513
 514 -> { "execute": "blockdev-add",
 515      "arguments": { { "node-name": "node0",
 516                       "driver": "raw",
 517                       "file": { "driver": "file",
 518                                 "filename": "fedora.iso" } } }
 519
 520 <- { "return": {} }
 521
 522 -> { "execute": "x-blockdev-insert-medium",
 523      "arguments": { "id": "ide0-1-0",
 524                     "node-name": "node0" } }
 525
 526 <- { "return": {} }
 527
 528 x-blockdev-change
 529 -----------------
 530
 531 Dynamically reconfigure the block driver state graph. It can be used
 532 to add, remove, insert or replace a graph node. Currently only the
 533 Quorum driver implements this feature to add or remove its child. This
 534 is useful to fix a broken quorum child.
 535
 536 If @node is specified, it will be inserted under @parent. @child
 537 may not be specified in this case. If both @parent and @child are
 538 specified but @node is not, @child will be detached from @parent.
 539
 540 Arguments:
 541 - "parent": the id or name of the parent node (json-string)
 542 - "child": the name of a child under the given parent node (json-string, optional)
 543 - "node": the name of the node that will be added (json-string, optional)
 544
 545 Note: this command is experimental, and not a stable API. It doesn't
 546 support all kinds of operations, all kinds of children, nor all block
 547 drivers.
 548
 549 Warning: The data in a new quorum child MUST be consistent with that of
 550 the rest of the array.
 551
 552 Example:
 553
 554 Add a new node to a quorum
 555 -> { "execute": "blockdev-add",
 556      "arguments": { "driver": "raw",
 557                     "node-name": "new_node",
 558                     "file": { "driver": "file",
 559                               "filename": "test.raw" } } }
 560 <- { "return": {} }
 561 -> { "execute": "x-blockdev-change",
 562      "arguments": { "parent": "disk1",
 563                     "node": "new_node" } }
 564 <- { "return": {} }
 565
 566 Delete a quorum's node
 567 -> { "execute": "x-blockdev-change",
 568      "arguments": { "parent": "disk1",
 569                     "child": "children.1" } }
 570 <- { "return": {} }
 571
 572 blockdev-change-medium
 573 ----------------------
 574
 575 Changes the medium inserted into a block device by ejecting the current medium
 576 and loading a new image file which is inserted as the new medium.
 577
 578 Arguments:
 579
 580 - "device": block device name (deprecated, use @id instead)
 581             (json-string, optional)
 582 - "id": the name or QOM path of the guest device (json-string, optional)
 583 - "filename": filename of the new image (json-string)
 584 - "format": format of the new image (json-string, optional)
 585 - "read-only-mode": new read-only mode (json-string, optional)
 586           - Possible values: "retain" (default), "read-only", "read-write"
 587
 588 Examples:
 589
 590 1. Change a removable medium
 591
 592 -> { "execute": "blockdev-change-medium",
 593              "arguments": { "id": "ide0-1-0",
 594                             "filename": "/srv/images/Fedora-12-x86_64-DVD.iso",
 595                             "format": "raw" } }
 596 <- { "return": {} }
 597
 598 2. Load a read-only medium into a writable drive
 599
 600 -> { "execute": "blockdev-change-medium",
 601              "arguments": { "id": "floppyA",
 602                             "filename": "/srv/images/ro.img",
 603                             "format": "raw",
 604                             "read-only-mode": "retain" } }
 605
 606 <- { "error":
 607      { "class": "GenericError",
 608        "desc": "Could not open '/srv/images/ro.img': Permission denied" } }
 609
 610 -> { "execute": "blockdev-change-medium",
 611              "arguments": { "id": "floppyA",
 612                             "filename": "/srv/images/ro.img",
 613                             "format": "raw",
 614                             "read-only-mode": "read-only" } }
 615
 616 <- { "return": {} }
 617
 618 trace-event-get-state
 619 ---------------------
 620
 621 Query the state of events.
 622
 623 Arguments:
 624
 625 - "name": Event name pattern (json-string).
 626 - "vcpu": The vCPU to query, any vCPU by default (json-int, optional).
 627
 628 An event is returned if:
 629 - its name matches the "name" pattern, and
 630 - if "vcpu" is given, the event has the "vcpu" property.
 631
 632 Therefore, if "vcpu" is given, the operation will only match per-vCPU events,
 633 returning their state on the specified vCPU. Special case: if "name" is an exact
 634 match, "vcpu" is given and the event does not have the "vcpu" property, an error
 635 is returned.
 636
 637 Example:
 638
 639 -> { "execute": "trace-event-get-state", "arguments": { "name": "qemu_memalign" } }
 640 <- { "return": [ { "name": "qemu_memalign", "state": "disabled" } ] }
 641
 642 trace-event-set-state
 643 ---------------------
 644
 645 Set the state of events.
 646
 647 Arguments:
 648
 649 - "name": Event name pattern (json-string).
 650 - "enable": Whether to enable or disable the event (json-bool).
 651 - "ignore-unavailable": Whether to ignore errors for events that cannot be
 652   changed (json-bool, optional).
 653 - "vcpu": The vCPU to act upon, all vCPUs by default (json-int, optional).
 654
 655 An event's state is modified if:
 656 - its name matches the "name" pattern, and
 657 - if "vcpu" is given, the event has the "vcpu" property.
 658
 659 Therefore, if "vcpu" is given, the operation will only match per-vCPU events,
 660 setting their state on the specified vCPU. Special case: if "name" is an exact
 661 match, "vcpu" is given and the event does not have the "vcpu" property, an error
 662 is returned.
 663
 664 Example:
 665
 666 -> { "execute": "trace-event-set-state", "arguments": { "name": "qemu_memalign", "enable": "true" } }
 667 <- { "return": {} }
 668
 669 block-set-write-threshold
 670 ------------
 671
 672 Change the write threshold for a block drive. The threshold is an offset,
 673 thus must be non-negative. Default is no write threshold.
 674 Setting the threshold to zero disables it.
 675
 676 Arguments:
 677
 678 - "node-name": the node name in the block driver state graph (json-string)
 679 - "write-threshold": the write threshold in bytes (json-int)
 680
 681 Example:
 682
 683 -> { "execute": "block-set-write-threshold",
 684   "arguments": { "node-name": "mydev",
 685                  "write-threshold": 17179869184 } }
 686 <- { "return": {} }
 687
 688 Show rocker switch
 689 ------------------
 690
 691 Arguments:
 692
 693 - "name": switch name
 694
 695 Example:
 696
 697 -> { "execute": "query-rocker", "arguments": { "name": "sw1" } }
 698 <- { "return": {"name": "sw1", "ports": 2, "id": 1327446905938}}
 699
 700 Show rocker switch ports
 701 ------------------------
 702
 703 Arguments:
 704
 705 - "name": switch name
 706
 707 Example:
 708
 709 -> { "execute": "query-rocker-ports", "arguments": { "name": "sw1" } }
 710 <- { "return": [ {"duplex": "full", "enabled": true, "name": "sw1.1",
 711                   "autoneg": "off", "link-up": true, "speed": 10000},
 712                  {"duplex": "full", "enabled": true, "name": "sw1.2",
 713                   "autoneg": "off", "link-up": true, "speed": 10000}
 714    ]}
 715
 716 Show rocker switch OF-DPA flow tables
 717 -------------------------------------
 718
 719 Arguments:
 720
 721 - "name": switch name
 722 - "tbl-id": (optional) flow table ID
 723
 724 Example:
 725
 726 -> { "execute": "query-rocker-of-dpa-flows", "arguments": { "name": "sw1" } }
 727 <- { "return": [ {"key": {"in-pport": 0, "priority": 1, "tbl-id": 0},
 728                   "hits": 138,
 729                   "cookie": 0,
 730                   "action": {"goto-tbl": 10},
 731                   "mask": {"in-pport": 4294901760}
 732                  },
 733                  {...more...},
 734    ]}
 735
 736 Show rocker OF-DPA group tables
 737 -------------------------------
 738
 739 Arguments:
 740
 741 - "name": switch name
 742 - "type": (optional) group type
 743
 744 Example:
 745
 746 -> { "execute": "query-rocker-of-dpa-groups", "arguments": { "name": "sw1" } }
 747 <- { "return": [ {"type": 0, "out-pport": 2, "pport": 2, "vlan-id": 3841,
 748                   "pop-vlan": 1, "id": 251723778},
 749                  {"type": 0, "out-pport": 0, "pport": 0, "vlan-id": 3841,
 750                   "pop-vlan": 1, "id": 251723776},
 751                  {"type": 0, "out-pport": 1, "pport": 1, "vlan-id": 3840,
 752                   "pop-vlan": 1, "id": 251658241},
 753                  {"type": 0, "out-pport": 0, "pport": 0, "vlan-id": 3840,
 754                   "pop-vlan": 1, "id": 251658240}
 755    ]}
 756
 757 query-gic-capabilities
 758 ---------------
 759
 760 Return a list of GICCapability objects, describing supported GIC
 761 (Generic Interrupt Controller) versions.
 762
 763 Arguments: None
 764
 765 Example:
 766
 767 -> { "execute": "query-gic-capabilities" }
 768 <- { "return": [{ "version": 2, "emulated": true, "kernel": false },
 769                 { "version": 3, "emulated": false, "kernel": true } ] }
 770
 771 Show existing/possible CPUs
 772 ---------------------------
 773
 774 Arguments: None.
 775
 776 Example for pseries machine type started with
 777 -smp 2,cores=2,maxcpus=4 -cpu POWER8:
 778
 779 -> { "execute": "query-hotpluggable-cpus" }
 780 <- {"return": [
 781      { "props": { "core-id": 8 }, "type": "POWER8-spapr-cpu-core",
 782        "vcpus-count": 1 },
 783      { "props": { "core-id": 0 }, "type": "POWER8-spapr-cpu-core",
 784        "vcpus-count": 1, "qom-path": "/machine/unattached/device[0]"}
 785    ]}'
 786
 787 Example for pc machine type started with
 788 -smp 1,maxcpus=2:
 789     -> { "execute": "query-hotpluggable-cpus" }
 790     <- {"return": [
 791          {
 792             "type": "qemu64-x86_64-cpu", "vcpus-count": 1,
 793             "props": {"core-id": 0, "socket-id": 1, "thread-id": 0}
 794          },
 795          {
 796             "qom-path": "/machine/unattached/device[0]",
 797             "type": "qemu64-x86_64-cpu", "vcpus-count": 1,
 798             "props": {"core-id": 0, "socket-id": 0, "thread-id": 0}
 799          }
 800        ]}