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 blockdev-open-tray
 347 ------------------
 348
 349 Opens a block device's tray. If there is a block driver state tree inserted as a
 350 medium, it will become inaccessible to the guest (but it will remain associated
 351 to the block device, so closing the tray will make it accessible again).
 352
 353 If the tray was already open before, this will be a no-op.
 354
 355 Once the tray opens, a DEVICE_TRAY_MOVED event is emitted. There are cases in
 356 which no such event will be generated, these include:
 357 - if the guest has locked the tray, @force is false and the guest does not
 358   respond to the eject request
 359 - if the BlockBackend denoted by @device does not have a guest device attached
 360   to it
 361 - if the guest device does not have an actual tray and is empty, for instance
 362   for floppy disk drives
 363
 364 Arguments:
 365
 366 - "device": block device name (deprecated, use @id instead)
 367             (json-string, optional)
 368 - "id": the name or QOM path of the guest device (json-string, optional)
 369 - "force": if false (the default), an eject request will be sent to the guest if
 370            it has locked the tray (and the tray will not be opened immediately);
 371            if true, the tray will be opened regardless of whether it is locked
 372            (json-bool, optional)
 373
 374 Example:
 375
 376 -> { "execute": "blockdev-open-tray",
 377      "arguments": { "id": "ide0-1-0" } }
 378
 379 <- { "timestamp": { "seconds": 1418751016,
 380                     "microseconds": 716996 },
 381      "event": "DEVICE_TRAY_MOVED",
 382      "data": { "device": "ide1-cd0",
 383                "id": "ide0-1-0",
 384                "tray-open": true } }
 385
 386 <- { "return": {} }
 387
 388 blockdev-close-tray
 389 -------------------
 390
 391 Closes a block device's tray. If there is a block driver state tree associated
 392 with the block device (which is currently ejected), that tree will be loaded as
 393 the medium.
 394
 395 If the tray was already closed before, this will be a no-op.
 396
 397 Arguments:
 398
 399 - "device": block device name (deprecated, use @id instead)
 400             (json-string, optional)
 401 - "id": the name or QOM path of the guest device (json-string, optional)
 402
 403 Example:
 404
 405 -> { "execute": "blockdev-close-tray",
 406      "arguments": { "id": "ide0-1-0" } }
 407
 408 <- { "timestamp": { "seconds": 1418751345,
 409                     "microseconds": 272147 },
 410      "event": "DEVICE_TRAY_MOVED",
 411      "data": { "device": "ide1-cd0",
 412                "id": "ide0-1-0",
 413                "tray-open": false } }
 414
 415 <- { "return": {} }
 416
 417 x-blockdev-remove-medium
 418 ------------------------
 419
 420 Removes a medium (a block driver state tree) from a block device. That block
 421 device's tray must currently be open (unless there is no attached guest device).
 422
 423 If the tray is open and there is no medium inserted, this will be a no-op.
 424
 425 This command is still a work in progress and is considered experimental.
 426 Stay away from it unless you want to help with its development.
 427
 428 Arguments:
 429
 430 - "device": block device name (deprecated, use @id instead)
 431             (json-string, optional)
 432 - "id": the name or QOM path of the guest device (json-string, optional)
 433
 434 Example:
 435
 436 -> { "execute": "x-blockdev-remove-medium",
 437      "arguments": { "id": "ide0-1-0" } }
 438
 439 <- { "error": { "class": "GenericError",
 440                 "desc": "Tray of device 'ide0-1-0' is not open" } }
 441
 442 -> { "execute": "blockdev-open-tray",
 443      "arguments": { "id": "ide0-1-0" } }
 444
 445 <- { "timestamp": { "seconds": 1418751627,
 446                     "microseconds": 549958 },
 447      "event": "DEVICE_TRAY_MOVED",
 448      "data": { "device": "ide1-cd0",
 449                "id": "ide0-1-0",
 450                "tray-open": true } }
 451
 452 <- { "return": {} }
 453
 454 -> { "execute": "x-blockdev-remove-medium",
 455      "arguments": { "device": "ide0-1-0" } }
 456
 457 <- { "return": {} }
 458
 459 x-blockdev-insert-medium
 460 ------------------------
 461
 462 Inserts a medium (a block driver state tree) into a block device. That block
 463 device's tray must currently be open (unless there is no attached guest device)
 464 and there must be no medium inserted already.
 465
 466 This command is still a work in progress and is considered experimental.
 467 Stay away from it unless you want to help with its development.
 468
 469 Arguments:
 470
 471 - "device": block device name (deprecated, use @id instead)
 472             (json-string, optional)
 473 - "id": the name or QOM path of the guest device (json-string, optional)
 474 - "node-name": root node of the BDS tree to insert into the block device
 475
 476 Example:
 477
 478 -> { "execute": "blockdev-add",
 479      "arguments": { { "node-name": "node0",
 480                       "driver": "raw",
 481                       "file": { "driver": "file",
 482                                 "filename": "fedora.iso" } } }
 483
 484 <- { "return": {} }
 485
 486 -> { "execute": "x-blockdev-insert-medium",
 487      "arguments": { "id": "ide0-1-0",
 488                     "node-name": "node0" } }
 489
 490 <- { "return": {} }
 491
 492 x-blockdev-change
 493 -----------------
 494
 495 Dynamically reconfigure the block driver state graph. It can be used
 496 to add, remove, insert or replace a graph node. Currently only the
 497 Quorum driver implements this feature to add or remove its child. This
 498 is useful to fix a broken quorum child.
 499
 500 If @node is specified, it will be inserted under @parent. @child
 501 may not be specified in this case. If both @parent and @child are
 502 specified but @node is not, @child will be detached from @parent.
 503
 504 Arguments:
 505 - "parent": the id or name of the parent node (json-string)
 506 - "child": the name of a child under the given parent node (json-string, optional)
 507 - "node": the name of the node that will be added (json-string, optional)
 508
 509 Note: this command is experimental, and not a stable API. It doesn't
 510 support all kinds of operations, all kinds of children, nor all block
 511 drivers.
 512
 513 Warning: The data in a new quorum child MUST be consistent with that of
 514 the rest of the array.
 515
 516 Example:
 517
 518 Add a new node to a quorum
 519 -> { "execute": "blockdev-add",
 520      "arguments": { "driver": "raw",
 521                     "node-name": "new_node",
 522                     "file": { "driver": "file",
 523                               "filename": "test.raw" } } }
 524 <- { "return": {} }
 525 -> { "execute": "x-blockdev-change",
 526      "arguments": { "parent": "disk1",
 527                     "node": "new_node" } }
 528 <- { "return": {} }
 529
 530 Delete a quorum's node
 531 -> { "execute": "x-blockdev-change",
 532      "arguments": { "parent": "disk1",
 533                     "child": "children.1" } }
 534 <- { "return": {} }
 535
 536 blockdev-change-medium
 537 ----------------------
 538
 539 Changes the medium inserted into a block device by ejecting the current medium
 540 and loading a new image file which is inserted as the new medium.
 541
 542 Arguments:
 543
 544 - "device": block device name (deprecated, use @id instead)
 545             (json-string, optional)
 546 - "id": the name or QOM path of the guest device (json-string, optional)
 547 - "filename": filename of the new image (json-string)
 548 - "format": format of the new image (json-string, optional)
 549 - "read-only-mode": new read-only mode (json-string, optional)
 550           - Possible values: "retain" (default), "read-only", "read-write"
 551
 552 Examples:
 553
 554 1. Change a removable medium
 555
 556 -> { "execute": "blockdev-change-medium",
 557              "arguments": { "id": "ide0-1-0",
 558                             "filename": "/srv/images/Fedora-12-x86_64-DVD.iso",
 559                             "format": "raw" } }
 560 <- { "return": {} }
 561
 562 2. Load a read-only medium into a writable drive
 563
 564 -> { "execute": "blockdev-change-medium",
 565              "arguments": { "id": "floppyA",
 566                             "filename": "/srv/images/ro.img",
 567                             "format": "raw",
 568                             "read-only-mode": "retain" } }
 569
 570 <- { "error":
 571      { "class": "GenericError",
 572        "desc": "Could not open '/srv/images/ro.img': Permission denied" } }
 573
 574 -> { "execute": "blockdev-change-medium",
 575              "arguments": { "id": "floppyA",
 576                             "filename": "/srv/images/ro.img",
 577                             "format": "raw",
 578                             "read-only-mode": "read-only" } }
 579
 580 <- { "return": {} }
 581
 582 trace-event-get-state
 583 ---------------------
 584
 585 Query the state of events.
 586
 587 Arguments:
 588
 589 - "name": Event name pattern (json-string).
 590 - "vcpu": The vCPU to query, any vCPU by default (json-int, optional).
 591
 592 An event is returned if:
 593 - its name matches the "name" pattern, and
 594 - if "vcpu" is given, the event has the "vcpu" property.
 595
 596 Therefore, if "vcpu" is given, the operation will only match per-vCPU events,
 597 returning their state on the specified vCPU. Special case: if "name" is an exact
 598 match, "vcpu" is given and the event does not have the "vcpu" property, an error
 599 is returned.
 600
 601 Example:
 602
 603 -> { "execute": "trace-event-get-state", "arguments": { "name": "qemu_memalign" } }
 604 <- { "return": [ { "name": "qemu_memalign", "state": "disabled" } ] }
 605
 606 trace-event-set-state
 607 ---------------------
 608
 609 Set the state of events.
 610
 611 Arguments:
 612
 613 - "name": Event name pattern (json-string).
 614 - "enable": Whether to enable or disable the event (json-bool).
 615 - "ignore-unavailable": Whether to ignore errors for events that cannot be
 616   changed (json-bool, optional).
 617 - "vcpu": The vCPU to act upon, all vCPUs by default (json-int, optional).
 618
 619 An event's state is modified if:
 620 - its name matches the "name" pattern, and
 621 - if "vcpu" is given, the event has the "vcpu" property.
 622
 623 Therefore, if "vcpu" is given, the operation will only match per-vCPU events,
 624 setting their state on the specified vCPU. Special case: if "name" is an exact
 625 match, "vcpu" is given and the event does not have the "vcpu" property, an error
 626 is returned.
 627
 628 Example:
 629
 630 -> { "execute": "trace-event-set-state", "arguments": { "name": "qemu_memalign", "enable": "true" } }
 631 <- { "return": {} }
 632
 633 block-set-write-threshold
 634 ------------
 635
 636 Change the write threshold for a block drive. The threshold is an offset,
 637 thus must be non-negative. Default is no write threshold.
 638 Setting the threshold to zero disables it.
 639
 640 Arguments:
 641
 642 - "node-name": the node name in the block driver state graph (json-string)
 643 - "write-threshold": the write threshold in bytes (json-int)
 644
 645 Example:
 646
 647 -> { "execute": "block-set-write-threshold",
 648   "arguments": { "node-name": "mydev",
 649                  "write-threshold": 17179869184 } }
 650 <- { "return": {} }
 651
 652 Show rocker switch
 653 ------------------
 654
 655 Arguments:
 656
 657 - "name": switch name
 658
 659 Example:
 660
 661 -> { "execute": "query-rocker", "arguments": { "name": "sw1" } }
 662 <- { "return": {"name": "sw1", "ports": 2, "id": 1327446905938}}
 663
 664 Show rocker switch ports
 665 ------------------------
 666
 667 Arguments:
 668
 669 - "name": switch name
 670
 671 Example:
 672
 673 -> { "execute": "query-rocker-ports", "arguments": { "name": "sw1" } }
 674 <- { "return": [ {"duplex": "full", "enabled": true, "name": "sw1.1",
 675                   "autoneg": "off", "link-up": true, "speed": 10000},
 676                  {"duplex": "full", "enabled": true, "name": "sw1.2",
 677                   "autoneg": "off", "link-up": true, "speed": 10000}
 678    ]}
 679
 680 Show rocker switch OF-DPA flow tables
 681 -------------------------------------
 682
 683 Arguments:
 684
 685 - "name": switch name
 686 - "tbl-id": (optional) flow table ID
 687
 688 Example:
 689
 690 -> { "execute": "query-rocker-of-dpa-flows", "arguments": { "name": "sw1" } }
 691 <- { "return": [ {"key": {"in-pport": 0, "priority": 1, "tbl-id": 0},
 692                   "hits": 138,
 693                   "cookie": 0,
 694                   "action": {"goto-tbl": 10},
 695                   "mask": {"in-pport": 4294901760}
 696                  },
 697                  {...more...},
 698    ]}
 699
 700 Show rocker OF-DPA group tables
 701 -------------------------------
 702
 703 Arguments:
 704
 705 - "name": switch name
 706 - "type": (optional) group type
 707
 708 Example:
 709
 710 -> { "execute": "query-rocker-of-dpa-groups", "arguments": { "name": "sw1" } }
 711 <- { "return": [ {"type": 0, "out-pport": 2, "pport": 2, "vlan-id": 3841,
 712                   "pop-vlan": 1, "id": 251723778},
 713                  {"type": 0, "out-pport": 0, "pport": 0, "vlan-id": 3841,
 714                   "pop-vlan": 1, "id": 251723776},
 715                  {"type": 0, "out-pport": 1, "pport": 1, "vlan-id": 3840,
 716                   "pop-vlan": 1, "id": 251658241},
 717                  {"type": 0, "out-pport": 0, "pport": 0, "vlan-id": 3840,
 718                   "pop-vlan": 1, "id": 251658240}
 719    ]}
 720
 721 query-gic-capabilities
 722 ---------------
 723
 724 Return a list of GICCapability objects, describing supported GIC
 725 (Generic Interrupt Controller) versions.
 726
 727 Arguments: None
 728
 729 Example:
 730
 731 -> { "execute": "query-gic-capabilities" }
 732 <- { "return": [{ "version": 2, "emulated": true, "kernel": false },
 733                 { "version": 3, "emulated": false, "kernel": true } ] }
 734
 735 Show existing/possible CPUs
 736 ---------------------------
 737
 738 Arguments: None.
 739
 740 Example for pseries machine type started with
 741 -smp 2,cores=2,maxcpus=4 -cpu POWER8:
 742
 743 -> { "execute": "query-hotpluggable-cpus" }
 744 <- {"return": [
 745      { "props": { "core-id": 8 }, "type": "POWER8-spapr-cpu-core",
 746        "vcpus-count": 1 },
 747      { "props": { "core-id": 0 }, "type": "POWER8-spapr-cpu-core",
 748        "vcpus-count": 1, "qom-path": "/machine/unattached/device[0]"}
 749    ]}'
 750
 751 Example for pc machine type started with
 752 -smp 1,maxcpus=2:
 753     -> { "execute": "query-hotpluggable-cpus" }
 754     <- {"return": [
 755          {
 756             "type": "qemu64-x86_64-cpu", "vcpus-count": 1,
 757             "props": {"core-id": 0, "socket-id": 1, "thread-id": 0}
 758          },
 759          {
 760             "qom-path": "/machine/unattached/device[0]",
 761             "type": "qemu64-x86_64-cpu", "vcpus-count": 1,
 762             "props": {"core-id": 0, "socket-id": 0, "thread-id": 0}
 763          }
 764        ]}