X-Git-Url: https://repo.jachan.dev/qemu.git/blobdiff_plain/8ff7fd8a29e62e685b3977f6db2c2f3661e96da9..2ccb98033353512a1cdf171fdc88047d5977c97d:/docs/qmp-commands.txt diff --git a/docs/qmp-commands.txt b/docs/qmp-commands.txt index 6afa87298d..e4c8457801 100644 --- a/docs/qmp-commands.txt +++ b/docs/qmp-commands.txt @@ -53,18 +53,6 @@ If you're planning to adopt QMP, please observe the following: Server's responses in the examples below are always a success response, please refer to the QMP specification for more details on error responses. -quit ----- - -Quit the emulator. - -Arguments: None. - -Example: - --> { "execute": "quit" } -<- { "return": {} } - eject ----- @@ -84,33 +72,6 @@ Example: Note: The "force" argument defaults to false. -change ------- - -Change a removable medium or VNC configuration. - -Arguments: - -- "device": device name (json-string) -- "target": filename or item (json-string) -- "arg": additional argument (json-string, optional) - -Examples: - -1. Change a removable medium - --> { "execute": "change", - "arguments": { "device": "ide1-cd0", - "target": "/srv/images/Fedora-12-x86_64-DVD.iso" } } -<- { "return": {} } - -2. Change VNC password - --> { "execute": "change", - "arguments": { "device": "vnc", "target": "password", - "arg": "foobar1" } } -<- { "return": {} } - screendump ---------- @@ -125,66 +86,6 @@ Example: -> { "execute": "screendump", "arguments": { "filename": "/tmp/image" } } <- { "return": {} } -stop ----- - -Stop the emulator. - -Arguments: None. - -Example: - --> { "execute": "stop" } -<- { "return": {} } - -cont ----- - -Resume emulation. - -Arguments: None. - -Example: - --> { "execute": "cont" } -<- { "return": {} } - -system_wakeup -------------- - -Wakeup guest from suspend. - -Arguments: None. - -Example: - --> { "execute": "system_wakeup" } -<- { "return": {} } - -system_reset ------------- - -Reset the system. - -Arguments: None. - -Example: - --> { "execute": "system_reset" } -<- { "return": {} } - -system_powerdown ----------------- - -Send system power down event. - -Arguments: None. - -Example: - --> { "execute": "system_powerdown" } -<- { "return": {} } - device_add ---------- @@ -210,25 +111,6 @@ Notes: (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 -device_del ----------- - -Remove a device. - -Arguments: - -- "id": the device's ID or QOM path (json-string) - -Example: - --> { "execute": "device_del", "arguments": { "id": "net1" } } -<- { "return": {} } - -Example: - --> { "execute": "device_del", "arguments": { "id": "/machine/peripheral-anon/device[0]" } } -<- { "return": {} } - send-key ---------- @@ -267,138 +149,6 @@ Example: Note: CPUs' indexes are obtained with the 'query-cpus' command. -cpu-add -------- - -Adds virtual cpu - -Arguments: - -- "id": cpu id (json-int) - -Example: - --> { "execute": "cpu-add", "arguments": { "id": 2 } } -<- { "return": {} } - -memsave -------- - -Save to disk virtual memory dump starting at 'val' of size 'size'. - -Arguments: - -- "val": the starting address (json-int) -- "size": the memory size, in bytes (json-int) -- "filename": file path (json-string) -- "cpu": virtual CPU index (json-int, optional) - -Example: - --> { "execute": "memsave", - "arguments": { "val": 10, - "size": 100, - "filename": "/tmp/virtual-mem-dump" } } -<- { "return": {} } - -pmemsave --------- - -Save to disk physical memory dump starting at 'val' of size 'size'. - -Arguments: - -- "val": the starting address (json-int) -- "size": the memory size, in bytes (json-int) -- "filename": file path (json-string) - -Example: - --> { "execute": "pmemsave", - "arguments": { "val": 10, - "size": 100, - "filename": "/tmp/physical-mem-dump" } } -<- { "return": {} } - -inject-nmi ----------- - -Inject an NMI on the default CPU (x86/s390) or all CPUs (ppc64). - -Arguments: None. - -Example: - --> { "execute": "inject-nmi" } -<- { "return": {} } - -Note: inject-nmi fails when the guest doesn't support injecting. - -ringbuf-write -------------- - -Write to a ring buffer character device. - -Arguments: - -- "device": ring buffer character device name (json-string) -- "data": data to write (json-string) -- "format": data format (json-string, optional) - - Possible values: "utf8" (default), "base64" - -Example: - --> { "execute": "ringbuf-write", - "arguments": { "device": "foo", - "data": "abcdefgh", - "format": "utf8" } } -<- { "return": {} } - -ringbuf-read -------------- - -Read from a ring buffer character device. - -Arguments: - -- "device": ring buffer character device name (json-string) -- "size": how many bytes to read at most (json-int) - - Number of data bytes, not number of characters in encoded data -- "format": data format (json-string, optional) - - Possible values: "utf8" (default), "base64" - - Naturally, format "utf8" works only when the ring buffer - contains valid UTF-8 text. Invalid UTF-8 sequences get - replaced. Bug: replacement doesn't work. Bug: can screw - up on encountering NUL characters, after the ring buffer - lost data, and when reading stops because the size limit - is reached. - -Example: - --> { "execute": "ringbuf-read", - "arguments": { "device": "foo", - "size": 1000, - "format": "utf8" } } -<- {"return": "abcdefgh"} - -xen-save-devices-state -------- - -Save the state of all devices to file. The RAM and the block devices -of the VM are not saved by this command. - -Arguments: - -- "filename": the file to save the state of the devices to as binary -data. See xen-save-devices-state.txt for a description of the binary -format. - -Example: - --> { "execute": "xen-save-devices-state", - "arguments": { "filename": "/tmp/save" } } -<- { "return": {} } - xen-load-devices-state ---------------------- @@ -417,77 +167,6 @@ Example: "arguments": { "filename": "/tmp/resume" } } <- { "return": {} } -xen-set-global-dirty-log -------- - -Enable or disable the global dirty log mode. - -Arguments: - -- "enable": Enable it or disable it. - -Example: - --> { "execute": "xen-set-global-dirty-log", - "arguments": { "enable": true } } -<- { "return": {} } - -migrate -------- - -Migrate to URI. - -Arguments: - -- "blk": block migration, full disk copy (json-bool, optional) -- "inc": incremental disk copy (json-bool, optional) -- "uri": Destination URI (json-string) - -Example: - --> { "execute": "migrate", "arguments": { "uri": "tcp:0:4446" } } -<- { "return": {} } - -Notes: - -(1) The 'query-migrate' command should be used to check migration's progress - and final result (this information is provided by the 'status' member) -(2) All boolean arguments default to false -(3) The user Monitor's "detach" argument is invalid in QMP and should not - be used - -migrate_cancel --------------- - -Cancel the current migration. - -Arguments: None. - -Example: - --> { "execute": "migrate_cancel" } -<- { "return": {} } - -migrate-incoming ----------------- - -Continue an incoming migration - -Arguments: - -- "uri": Source/listening URI (json-string) - -Example: - --> { "execute": "migrate-incoming", "arguments": { "uri": "tcp::4446" } } -<- { "return": {} } - -Notes: - -(1) QEMU must be started with -incoming defer to allow migrate-incoming to - be used -(2) The uri format is the same as for -incoming - migrate-set-cache-size ---------------------- @@ -503,57 +182,6 @@ Example: -> { "execute": "migrate-set-cache-size", "arguments": { "value": 536870912 } } <- { "return": {} } -migrate-start-postcopy ----------------------- - -Switch an in-progress migration to postcopy mode. Ignored after the end of -migration (or once already in postcopy). - -Example: --> { "execute": "migrate-start-postcopy" } -<- { "return": {} } - -query-migrate-cache-size ------------------------- - -Show cache size to be used by XBZRLE migration - -returns a json-object with the following information: -- "size" : json-int - -Example: - --> { "execute": "query-migrate-cache-size" } -<- { "return": 67108864 } - -migrate_set_speed ------------------ - -Set maximum speed for migrations. - -Arguments: - -- "value": maximum speed, in bytes per second (json-int) - -Example: - --> { "execute": "migrate_set_speed", "arguments": { "value": 1024 } } -<- { "return": {} } - -migrate_set_downtime --------------------- - -Set maximum tolerated downtime (in seconds) for migrations. - -Arguments: - -- "value": maximum downtime (json-number) - -Example: - --> { "execute": "migrate_set_downtime", "arguments": { "value": 0.1 } } -<- { "return": {} } - x-colo-lost-heartbeat -------------------- @@ -564,70 +192,6 @@ Example: -> { "execute": "x-colo-lost-heartbeat" } <- { "return": {} } -client_migrate_info -------------------- - -Set migration information for remote display. This makes the server -ask the client to automatically reconnect using the new parameters -once migration finished successfully. Only implemented for SPICE. - -Arguments: - -- "protocol": must be "spice" (json-string) -- "hostname": migration target hostname (json-string) -- "port": spice tcp port for plaintext channels (json-int, optional) -- "tls-port": spice tcp port for tls-secured channels (json-int, optional) -- "cert-subject": server certificate subject (json-string, optional) - -Example: - --> { "execute": "client_migrate_info", - "arguments": { "protocol": "spice", - "hostname": "virt42.lab.kraxel.org", - "port": 1234 } } -<- { "return": {} } - -dump - - -Dump guest memory to file. The file can be processed with crash or gdb. - -Arguments: - -- "paging": do paging to get guest's memory mapping (json-bool) -- "protocol": destination file(started with "file:") or destination file - descriptor (started with "fd:") (json-string) -- "detach": if specified, command will return immediately, without waiting - for the dump to finish. The user can track progress using - "query-dump". (json-bool) -- "begin": the starting physical address. It's optional, and should be specified - with length together (json-int) -- "length": the memory size, in bytes. It's optional, and should be specified - with begin together (json-int) -- "format": the format of guest memory dump. It's optional, and can be - elf|kdump-zlib|kdump-lzo|kdump-snappy, but non-elf formats will - conflict with paging and filter, ie. begin and length (json-string) - -Example: - --> { "execute": "dump-guest-memory", "arguments": { "protocol": "fd:dump" } } -<- { "return": {} } - -Notes: - -(1) All boolean arguments default to false - -query-dump-guest-memory-capability ----------- - -Show available formats for 'dump-guest-memory' - -Example: - --> { "execute": "query-dump-guest-memory-capability" } -<- { "return": { "formats": - ["elf", "kdump-zlib", "kdump-lzo", "kdump-snappy"] } - query-dump ---------- @@ -918,92 +482,6 @@ Example: "target": "tgt-id" } } <- { "return": {} } -transaction ------------ - -Atomically operate on one or more block devices. Operations that are -currently supported: - - - drive-backup - - blockdev-backup - - blockdev-snapshot-sync - - blockdev-snapshot-internal-sync - - abort - - block-dirty-bitmap-add - - block-dirty-bitmap-clear - -Refer to the qemu/qapi-schema.json file for minimum required QEMU -versions for these operations. A list of dictionaries is accepted, -that contains the actions to be performed. If there is any failure -performing any of the operations, all operations for the group are -abandoned. - -For external snapshots, the dictionary contains the device, the file to use for -the new snapshot, and the format. The default format, if not specified, is -qcow2. - -Each new snapshot defaults to being created by QEMU (wiping any -contents if the file already exists), but it is also possible to reuse -an externally-created file. In the latter case, you should ensure that -the new image file has the same contents as the current one; QEMU cannot -perform any meaningful check. Typically this is achieved by using the -current image file as the backing file for the new image. - -On failure, the original disks pre-snapshot attempt will be used. - -For internal snapshots, the dictionary contains the device and the snapshot's -name. If an internal snapshot matching name already exists, the request will -be rejected. Only some image formats support it, for example, qcow2, rbd, -and sheepdog. - -On failure, qemu will try delete the newly created internal snapshot in the -transaction. When an I/O error occurs during deletion, the user needs to fix -it later with qemu-img or other command. - -Arguments: - -actions array: - - "type": the operation to perform (json-string). Possible - values: "drive-backup", "blockdev-backup", - "blockdev-snapshot-sync", - "blockdev-snapshot-internal-sync", - "abort", "block-dirty-bitmap-add", - "block-dirty-bitmap-clear" - - "data": a dictionary. The contents depend on the value - of "type". When "type" is "blockdev-snapshot-sync": - - "device": device name to snapshot (json-string) - - "node-name": graph node name to snapshot (json-string) - - "snapshot-file": name of new image file (json-string) - - "snapshot-node-name": graph node name of the new snapshot (json-string) - - "format": format of new image (json-string, optional) - - "mode": whether and how QEMU should create the snapshot file - (NewImageMode, optional, default "absolute-paths") - When "type" is "blockdev-snapshot-internal-sync": - - "device": the device name or node-name of a root node to snapshot - (json-string) - - "name": name of the new snapshot (json-string) - -Example: - --> { "execute": "transaction", - "arguments": { "actions": [ - { "type": "blockdev-snapshot-sync", "data" : { "device": "ide-hd0", - "snapshot-file": "/some/place/my-image", - "format": "qcow2" } }, - { "type": "blockdev-snapshot-sync", "data" : { "node-name": "myfile", - "snapshot-file": "/some/place/my-image2", - "snapshot-node-name": "node3432", - "mode": "existing", - "format": "qcow2" } }, - { "type": "blockdev-snapshot-sync", "data" : { "device": "ide-hd1", - "snapshot-file": "/some/place/my-image2", - "mode": "existing", - "format": "qcow2" } }, - { "type": "blockdev-snapshot-internal-sync", "data" : { - "device": "ide-hd2", - "name": "snapshot0" } } ] } } -<- { "return": {} } - block-dirty-bitmap-add ---------------------- Since 2.4 @@ -1293,35 +771,6 @@ Arguments: Returns: Nothing on success If "device" does not exist or cannot be determined, DeviceNotFound -balloon -------- - -Request VM to change its memory allocation (in bytes). - -Arguments: - -- "value": New memory allocation (json-int) - -Example: - --> { "execute": "balloon", "arguments": { "value": 536870912 } } -<- { "return": {} } - -set_link --------- - -Change the link status of a network adapter. - -Arguments: - -- "name": network device name (json-string) -- "up": status is up (json-bool) - -Example: - --> { "execute": "set_link", "arguments": { "name": "e1000.0", "up": false } } -<- { "return": {} } - getfd ----- @@ -1515,57 +964,6 @@ Example: "iops_size": 0 } } <- { "return": {} } -set_password ------------- - -Set the password for vnc/spice protocols. - -Arguments: - -- "protocol": protocol name (json-string) -- "password": password (json-string) -- "connected": [ keep | disconnect | fail ] (json-string, optional) - -Example: - --> { "execute": "set_password", "arguments": { "protocol": "vnc", - "password": "secret" } } -<- { "return": {} } - -expire_password ---------------- - -Set the password expire time for vnc/spice protocols. - -Arguments: - -- "protocol": protocol name (json-string) -- "time": [ now | never | +secs | secs ] (json-string) - -Example: - --> { "execute": "expire_password", "arguments": { "protocol": "vnc", - "time": "+60" } } -<- { "return": {} } - -add_client ----------- - -Add a graphics client - -Arguments: - -- "protocol": protocol name (json-string) -- "fdname": file descriptor name (json-string) -- "skipauth": whether to skip authentication (json-bool, optional) -- "tls": whether to perform TLS (json-bool, optional) - -Example: - --> { "execute": "add_client", "arguments": { "protocol": "vnc", - "fdname": "myclient" } } -<- { "return": {} } - qmp_capabilities ---------------- @@ -1580,39 +978,6 @@ Example: Note: This command must be issued before issuing any other command. -human-monitor-command ---------------------- - -Execute a Human Monitor command. - -Arguments: - -- command-line: the command name and its arguments, just like the - Human Monitor's shell (json-string) -- cpu-index: select the CPU number to be used by commands which access CPU - data, like 'info registers'. The Monitor selects CPU 0 if this - argument is not provided (json-int, optional) - -Example: - --> { "execute": "human-monitor-command", "arguments": { "command-line": "info kvm" } } -<- { "return": "kvm support: enabled\r\n" } - -Notes: - -(1) The Human Monitor is NOT an stable interface, this means that command - names, arguments and responses can change or be removed at ANY time. - Applications that rely on long term stability guarantees should NOT - use this command - -(2) Limitations: - - o This command is stateless, this means that commands that depend - on state information (such as getfd) might not work - - o Commands that prompt the user for data (eg. 'cont' when the block - device is encrypted) don't currently work - 3. Query Commands ================= @@ -1636,146 +1001,50 @@ Example: <- { "return":{ "qemu":{ - "major":0, - "minor":11, - "micro":5 - }, - "package":"" - } - } - -query-commands --------------- - -List QMP available commands. - -Each command is represented by a json-object, the returned value is a json-array -of all commands. - -Each json-object contain: - -- "name": command's name (json-string) - -Example: - --> { "execute": "query-commands" } -<- { - "return":[ - { - "name":"query-balloon" - }, - { - "name":"system_powerdown" - } - ] - } - -Note: This example has been shortened as the real response is too long. - -query-events --------------- - -List QMP available events. - -Each event is represented by a json-object, the returned value is a json-array -of all events. - -Each json-object contains: - -- "name": event's name (json-string) - -Example: - --> { "execute": "query-events" } -<- { - "return":[ - { - "name":"SHUTDOWN" - }, - { - "name":"RESET" - } - ] - } - -Note: This example has been shortened as the real response is too long. - -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. - -query-chardev -------------- - -Each device is represented by a json-object. The returned value is a json-array -of all devices. - -Each json-object contain the following: - -- "label": device's label (json-string) -- "filename": device's file (json-string) -- "frontend-open": open/closed state of the frontend device attached to this - backend (json-bool) - -Example: - --> { "execute": "query-chardev" } -<- { - "return": [ - { - "label": "charchannel0", - "filename": "unix:/var/lib/libvirt/qemu/seabios.rhel6.agent,server", - "frontend-open": false - }, - { - "label": "charmonitor", - "filename": "unix:/var/lib/libvirt/qemu/seabios.rhel6.monitor,server", - "frontend-open": true + "major":0, + "minor":11, + "micro":5 }, - { - "label": "charserial0", - "filename": "pty:/dev/pts/2", - "frontend-open": true - } - ] + "package":"" + } } -query-chardev-backends -------------- +query-commands +-------------- -List available character device backends. +List QMP available commands. -Each backend is represented by a json-object, the returned value is a json-array -of all backends. +Each command is represented by a json-object, the returned value is a json-array +of all commands. -Each json-object contains: +Each json-object contain: -- "name": backend name (json-string) +- "name": command's name (json-string) Example: --> { "execute": "query-chardev-backends" } +-> { "execute": "query-commands" } <- { "return":[ { - "name":"udp" - }, - { - "name":"tcp" - }, - { - "name":"unix" + "name":"query-balloon" }, { - "name":"spiceport" + "name":"system_powerdown" } ] } +Note: This example has been shortened as the real response is too long. + +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. + query-block ----------- @@ -1803,7 +1072,7 @@ Each json-object contain the following: "file", "file", "ftp", "ftps", "host_cdrom", "host_device", "http", "https", "nbd", "parallels", "qcow", "qcow2", "raw", - "tftp", "vdi", "vmdk", "vpc", "vvfat" + "vdi", "vmdk", "vpc", "vvfat" - "backing_file": backing file name (json-string, optional) - "backing_file_depth": number of files in the backing file chain (json-int) - "encrypted": true if encrypted, false otherwise (json-bool) @@ -2139,520 +1408,6 @@ Example: ] } -query-cpus ----------- - -Show CPU information. - -Return a json-array. Each CPU is represented by a json-object, which contains: - -- "CPU": CPU index (json-int) -- "current": true if this is the current CPU, false otherwise (json-bool) -- "halted": true if the cpu is halted, false otherwise (json-bool) -- "qom_path": path to the CPU object in the QOM tree (json-str) -- "arch": architecture of the cpu, which determines what additional - keys will be present (json-str) -- Current program counter. The key's name depends on the architecture: - "pc": i386/x86_64 (json-int) - "nip": PPC (json-int) - "pc" and "npc": sparc (json-int) - "PC": mips (json-int) -- "thread_id": ID of the underlying host thread (json-int) - -Example: - --> { "execute": "query-cpus" } -<- { - "return":[ - { - "CPU":0, - "current":true, - "halted":false, - "qom_path":"/machine/unattached/device[0]", - "arch":"x86", - "pc":3227107138, - "thread_id":3134 - }, - { - "CPU":1, - "current":false, - "halted":true, - "qom_path":"/machine/unattached/device[2]", - "arch":"x86", - "pc":7108165, - "thread_id":3135 - } - ] - } - -query-iothreads ---------------- - -Returns a list of information about each iothread. - -Note this list excludes the QEMU main loop thread, which is not declared -using the -object iothread command-line option. It is always the main thread -of the process. - -Return a json-array. Each iothread is represented by a json-object, which contains: - -- "id": name of iothread (json-str) -- "thread-id": ID of the underlying host thread (json-int) - -Example: - --> { "execute": "query-iothreads" } -<- { - "return":[ - { - "id":"iothread0", - "thread-id":3134 - }, - { - "id":"iothread1", - "thread-id":3135 - } - ] - } - -query-pci ---------- - -PCI buses and devices information. - -The returned value is a json-array of all buses. Each bus is represented by -a json-object, which has a key with a json-array of all PCI devices attached -to it. Each device is represented by a json-object. - -The bus json-object contains the following: - -- "bus": bus number (json-int) -- "devices": a json-array of json-objects, each json-object represents a - PCI device - -The PCI device json-object contains the following: - -- "bus": identical to the parent's bus number (json-int) -- "slot": slot number (json-int) -- "function": function number (json-int) -- "class_info": a json-object containing: - - "desc": device class description (json-string, optional) - - "class": device class number (json-int) -- "id": a json-object containing: - - "device": device ID (json-int) - - "vendor": vendor ID (json-int) -- "irq": device's IRQ if assigned (json-int, optional) -- "qdev_id": qdev id string (json-string) -- "pci_bridge": It's a json-object, only present if this device is a - PCI bridge, contains: - - "bus": bus number (json-int) - - "secondary": secondary bus number (json-int) - - "subordinate": subordinate bus number (json-int) - - "io_range": I/O memory range information, a json-object with the - following members: - - "base": base address, in bytes (json-int) - - "limit": limit address, in bytes (json-int) - - "memory_range": memory range information, a json-object with the - following members: - - "base": base address, in bytes (json-int) - - "limit": limit address, in bytes (json-int) - - "prefetchable_range": Prefetchable memory range information, a - json-object with the following members: - - "base": base address, in bytes (json-int) - - "limit": limit address, in bytes (json-int) - - "devices": a json-array of PCI devices if there's any attached, each - each element is represented by a json-object, which contains - the same members of the 'PCI device json-object' described - above (optional) -- "regions": a json-array of json-objects, each json-object represents a - memory region of this device - -The memory range json-object contains the following: - -- "base": base memory address (json-int) -- "limit": limit value (json-int) - -The region json-object can be an I/O region or a memory region, an I/O region -json-object contains the following: - -- "type": "io" (json-string, fixed) -- "bar": BAR number (json-int) -- "address": memory address (json-int) -- "size": memory size (json-int) - -A memory region json-object contains the following: - -- "type": "memory" (json-string, fixed) -- "bar": BAR number (json-int) -- "address": memory address (json-int) -- "size": memory size (json-int) -- "mem_type_64": true or false (json-bool) -- "prefetch": true or false (json-bool) - -Example: - --> { "execute": "query-pci" } -<- { - "return":[ - { - "bus":0, - "devices":[ - { - "bus":0, - "qdev_id":"", - "slot":0, - "class_info":{ - "class":1536, - "desc":"Host bridge" - }, - "id":{ - "device":32902, - "vendor":4663 - }, - "function":0, - "regions":[ - - ] - }, - { - "bus":0, - "qdev_id":"", - "slot":1, - "class_info":{ - "class":1537, - "desc":"ISA bridge" - }, - "id":{ - "device":32902, - "vendor":28672 - }, - "function":0, - "regions":[ - - ] - }, - { - "bus":0, - "qdev_id":"", - "slot":1, - "class_info":{ - "class":257, - "desc":"IDE controller" - }, - "id":{ - "device":32902, - "vendor":28688 - }, - "function":1, - "regions":[ - { - "bar":4, - "size":16, - "address":49152, - "type":"io" - } - ] - }, - { - "bus":0, - "qdev_id":"", - "slot":2, - "class_info":{ - "class":768, - "desc":"VGA controller" - }, - "id":{ - "device":4115, - "vendor":184 - }, - "function":0, - "regions":[ - { - "prefetch":true, - "mem_type_64":false, - "bar":0, - "size":33554432, - "address":4026531840, - "type":"memory" - }, - { - "prefetch":false, - "mem_type_64":false, - "bar":1, - "size":4096, - "address":4060086272, - "type":"memory" - }, - { - "prefetch":false, - "mem_type_64":false, - "bar":6, - "size":65536, - "address":-1, - "type":"memory" - } - ] - }, - { - "bus":0, - "qdev_id":"", - "irq":11, - "slot":4, - "class_info":{ - "class":1280, - "desc":"RAM controller" - }, - "id":{ - "device":6900, - "vendor":4098 - }, - "function":0, - "regions":[ - { - "bar":0, - "size":32, - "address":49280, - "type":"io" - } - ] - } - ] - } - ] - } - -Note: This example has been shortened as the real response is too long. - -query-kvm ---------- - -Show KVM information. - -Return a json-object with the following information: - -- "enabled": true if KVM support is enabled, false otherwise (json-bool) -- "present": true if QEMU has KVM support, false otherwise (json-bool) - -Example: - --> { "execute": "query-kvm" } -<- { "return": { "enabled": true, "present": true } } - -query-status ------------- - -Return a json-object with the following information: - -- "running": true if the VM is running, or false if it is paused (json-bool) -- "singlestep": true if the VM is in single step mode, - false otherwise (json-bool) -- "status": one of the following values (json-string) - "debug" - QEMU is running on a debugger - "inmigrate" - guest is paused waiting for an incoming migration - "internal-error" - An internal error that prevents further guest - execution has occurred - "io-error" - the last IOP has failed and the device is configured - to pause on I/O errors - "paused" - guest has been paused via the 'stop' command - "postmigrate" - guest is paused following a successful 'migrate' - "prelaunch" - QEMU was started with -S and guest has not started - "finish-migrate" - guest is paused to finish the migration process - "restore-vm" - guest is paused to restore VM state - "running" - guest is actively running - "save-vm" - guest is paused to save the VM state - "shutdown" - guest is shut down (and -no-shutdown is in use) - "watchdog" - the watchdog action is configured to pause and - has been triggered - -Example: - --> { "execute": "query-status" } -<- { "return": { "running": true, "singlestep": false, "status": "running" } } - -query-mice ----------- - -Show VM mice information. - -Each mouse is represented by a json-object, the returned value is a json-array -of all mice. - -The mouse json-object contains the following: - -- "name": mouse's name (json-string) -- "index": mouse's index (json-int) -- "current": true if this mouse is receiving events, false otherwise (json-bool) -- "absolute": true if the mouse generates absolute input events (json-bool) - -Example: - --> { "execute": "query-mice" } -<- { - "return":[ - { - "name":"QEMU Microsoft Mouse", - "index":0, - "current":false, - "absolute":false - }, - { - "name":"QEMU PS/2 Mouse", - "index":1, - "current":true, - "absolute":true - } - ] - } - -query-vnc ---------- - -Show VNC server information. - -Return a json-object with server information. Connected clients are returned -as a json-array of json-objects. - -The main json-object contains the following: - -- "enabled": true or false (json-bool) -- "host": server's IP address (json-string) -- "family": address family (json-string) - - Possible values: "ipv4", "ipv6", "unix", "unknown" -- "service": server's port number (json-string) -- "auth": authentication method (json-string) - - Possible values: "invalid", "none", "ra2", "ra2ne", "sasl", "tight", - "tls", "ultra", "unknown", "vencrypt", "vencrypt", - "vencrypt+plain", "vencrypt+tls+none", - "vencrypt+tls+plain", "vencrypt+tls+sasl", - "vencrypt+tls+vnc", "vencrypt+x509+none", - "vencrypt+x509+plain", "vencrypt+x509+sasl", - "vencrypt+x509+vnc", "vnc" -- "clients": a json-array of all connected clients - -Clients are described by a json-object, each one contain the following: - -- "host": client's IP address (json-string) -- "family": address family (json-string) - - Possible values: "ipv4", "ipv6", "unix", "unknown" -- "service": client's port number (json-string) -- "x509_dname": TLS dname (json-string, optional) -- "sasl_username": SASL username (json-string, optional) - -Example: - --> { "execute": "query-vnc" } -<- { - "return":{ - "enabled":true, - "host":"0.0.0.0", - "service":"50402", - "auth":"vnc", - "family":"ipv4", - "clients":[ - { - "host":"127.0.0.1", - "service":"50401", - "family":"ipv4" - } - ] - } - } - -query-spice ------------ - -Show SPICE server information. - -Return a json-object with server information. Connected clients are returned -as a json-array of json-objects. - -The main json-object contains the following: - -- "enabled": true or false (json-bool) -- "host": server's IP address (json-string) -- "port": server's port number (json-int, optional) -- "tls-port": server's port number (json-int, optional) -- "auth": authentication method (json-string) - - Possible values: "none", "spice" -- "channels": a json-array of all active channels clients - -Channels are described by a json-object, each one contain the following: - -- "host": client's IP address (json-string) -- "family": address family (json-string) - - Possible values: "ipv4", "ipv6", "unix", "unknown" -- "port": client's port number (json-string) -- "connection-id": spice connection id. All channels with the same id - belong to the same spice session (json-int) -- "channel-type": channel type. "1" is the main control channel, filter for - this one if you want track spice sessions only (json-int) -- "channel-id": channel id. Usually "0", might be different needed when - multiple channels of the same type exist, such as multiple - display channels in a multihead setup (json-int) -- "tls": whether the channel is encrypted (json-bool) - -Example: - --> { "execute": "query-spice" } -<- { - "return": { - "enabled": true, - "auth": "spice", - "port": 5920, - "tls-port": 5921, - "host": "0.0.0.0", - "channels": [ - { - "port": "54924", - "family": "ipv4", - "channel-type": 1, - "connection-id": 1804289383, - "host": "127.0.0.1", - "channel-id": 0, - "tls": true - }, - { - "port": "36710", - "family": "ipv4", - "channel-type": 4, - "connection-id": 1804289383, - "host": "127.0.0.1", - "channel-id": 0, - "tls": false - }, - [ ... more channels follow ... ] - ] - } - } - -query-name ----------- - -Show VM name. - -Return a json-object with the following information: - -- "name": VM's name (json-string, optional) - -Example: - --> { "execute": "query-name" } -<- { "return": { "name": "qemu-name" } } - -query-uuid ----------- - -Show VM UUID. - -Return a json-object with the following information: - -- "UUID": Universally Unique Identifier (json-string) - -Example: - --> { "execute": "query-uuid" } -<- { "return": { "UUID": "550e8400-e29b-41d4-a716-446655440000" } } - query-command-line-options -------------------------- @@ -2693,304 +1448,6 @@ Example: ] } -query-migrate -------------- - -Migration status. - -Return a json-object. If migration is active there will be another json-object -with RAM migration status and if block migration is active another one with -block migration status. - -The main json-object contains the following: - -- "status": migration status (json-string) - - Possible values: "setup", "active", "completed", "failed", "cancelled" -- "total-time": total amount of ms since migration started. If - migration has ended, it returns the total migration - time (json-int) -- "setup-time" amount of setup time in milliseconds _before_ the - iterations begin but _after_ the QMP command is issued. - This is designed to provide an accounting of any activities - (such as RDMA pinning) which may be expensive, but do not - actually occur during the iterative migration rounds - themselves. (json-int) -- "downtime": only present when migration has finished correctly - total amount in ms for downtime that happened (json-int) -- "expected-downtime": only present while migration is active - total amount in ms for downtime that was calculated on - the last bitmap round (json-int) -- "ram": only present if "status" is "active", it is a json-object with the - following RAM information: - - "transferred": amount transferred in bytes (json-int) - - "remaining": amount remaining to transfer in bytes (json-int) - - "total": total amount of memory in bytes (json-int) - - "duplicate": number of pages filled entirely with the same - byte (json-int) - These are sent over the wire much more efficiently. - - "skipped": number of skipped zero pages (json-int) - - "normal" : number of whole pages transferred. I.e. they - were not sent as duplicate or xbzrle pages (json-int) - - "normal-bytes" : number of bytes transferred in whole - pages. This is just normal pages times size of one page, - but this way upper levels don't need to care about page - size (json-int) - - "dirty-sync-count": times that dirty ram was synchronized (json-int) -- "disk": only present if "status" is "active" and it is a block migration, - it is a json-object with the following disk information: - - "transferred": amount transferred in bytes (json-int) - - "remaining": amount remaining to transfer in bytes json-int) - - "total": total disk size in bytes (json-int) -- "xbzrle-cache": only present if XBZRLE is active. - It is a json-object with the following XBZRLE information: - - "cache-size": XBZRLE cache size in bytes - - "bytes": number of bytes transferred for XBZRLE compressed pages - - "pages": number of XBZRLE compressed pages - - "cache-miss": number of XBRZRLE page cache misses - - "cache-miss-rate": rate of XBRZRLE page cache misses - - "overflow": number of times XBZRLE overflows. This means - that the XBZRLE encoding was bigger than just sent the - whole page, and then we sent the whole page instead (as as - normal page). - -Examples: - -1. Before the first migration - --> { "execute": "query-migrate" } -<- { "return": {} } - -2. Migration is done and has succeeded - --> { "execute": "query-migrate" } -<- { "return": { - "status": "completed", - "ram":{ - "transferred":123, - "remaining":123, - "total":246, - "total-time":12345, - "setup-time":12345, - "downtime":12345, - "duplicate":123, - "normal":123, - "normal-bytes":123456, - "dirty-sync-count":15 - } - } - } - -3. Migration is done and has failed - --> { "execute": "query-migrate" } -<- { "return": { "status": "failed" } } - -4. Migration is being performed and is not a block migration: - --> { "execute": "query-migrate" } -<- { - "return":{ - "status":"active", - "ram":{ - "transferred":123, - "remaining":123, - "total":246, - "total-time":12345, - "setup-time":12345, - "expected-downtime":12345, - "duplicate":123, - "normal":123, - "normal-bytes":123456, - "dirty-sync-count":15 - } - } - } - -5. Migration is being performed and is a block migration: - --> { "execute": "query-migrate" } -<- { - "return":{ - "status":"active", - "ram":{ - "total":1057024, - "remaining":1053304, - "transferred":3720, - "total-time":12345, - "setup-time":12345, - "expected-downtime":12345, - "duplicate":123, - "normal":123, - "normal-bytes":123456, - "dirty-sync-count":15 - }, - "disk":{ - "total":20971520, - "remaining":20880384, - "transferred":91136 - } - } - } - -6. Migration is being performed and XBZRLE is active: - --> { "execute": "query-migrate" } -<- { - "return":{ - "status":"active", - "capabilities" : [ { "capability": "xbzrle", "state" : true } ], - "ram":{ - "total":1057024, - "remaining":1053304, - "transferred":3720, - "total-time":12345, - "setup-time":12345, - "expected-downtime":12345, - "duplicate":10, - "normal":3333, - "normal-bytes":3412992, - "dirty-sync-count":15 - }, - "xbzrle-cache":{ - "cache-size":67108864, - "bytes":20971520, - "pages":2444343, - "cache-miss":2244, - "cache-miss-rate":0.123, - "overflow":34434 - } - } - } - -migrate-set-capabilities ------------------------- - -Enable/Disable migration capabilities - -- "xbzrle": XBZRLE support -- "rdma-pin-all": pin all pages when using RDMA during migration -- "auto-converge": throttle down guest to help convergence of migration -- "zero-blocks": compress zero blocks during block migration -- "compress": use multiple compression threads to accelerate live migration -- "events": generate events for each migration state change -- "postcopy-ram": postcopy mode for live migration -- "x-colo": COarse-Grain LOck Stepping (COLO) for Non-stop Service - -Arguments: - -Example: - --> { "execute": "migrate-set-capabilities" , "arguments": - { "capabilities": [ { "capability": "xbzrle", "state": true } ] } } - -query-migrate-capabilities --------------------------- - -Query current migration capabilities - -- "capabilities": migration capabilities state - - "xbzrle" : XBZRLE state (json-bool) - - "rdma-pin-all" : RDMA Pin Page state (json-bool) - - "auto-converge" : Auto Converge state (json-bool) - - "zero-blocks" : Zero Blocks state (json-bool) - - "compress": Multiple compression threads state (json-bool) - - "events": Migration state change event state (json-bool) - - "postcopy-ram": postcopy ram state (json-bool) - - "x-colo": COarse-Grain LOck Stepping for Non-stop Service (json-bool) - -Arguments: - -Example: - --> { "execute": "query-migrate-capabilities" } -<- {"return": [ - {"state": false, "capability": "xbzrle"}, - {"state": false, "capability": "rdma-pin-all"}, - {"state": false, "capability": "auto-converge"}, - {"state": false, "capability": "zero-blocks"}, - {"state": false, "capability": "compress"}, - {"state": true, "capability": "events"}, - {"state": false, "capability": "postcopy-ram"}, - {"state": false, "capability": "x-colo"} - ]} - -migrate-set-parameters ----------------------- - -Set migration parameters - -- "compress-level": set compression level during migration (json-int) -- "compress-threads": set compression thread count for migration (json-int) -- "decompress-threads": set decompression thread count for migration (json-int) -- "cpu-throttle-initial": set initial percentage of time guest cpus are - throttled for auto-converge (json-int) -- "cpu-throttle-increment": set throttle increasing percentage for - auto-converge (json-int) -- "max-bandwidth": set maximum speed for migrations (in bytes/sec) (json-int) -- "downtime-limit": set maximum tolerated downtime (in milliseconds) for - migrations (json-int) -- "x-checkpoint-delay": set the delay time for periodic checkpoint (json-int) - -Arguments: - -Example: - --> { "execute": "migrate-set-parameters" , "arguments": - { "compress-level": 1 } } - -query-migrate-parameters ------------------------- - -Query current migration parameters - -- "parameters": migration parameters value - - "compress-level" : compression level value (json-int) - - "compress-threads" : compression thread count value (json-int) - - "decompress-threads" : decompression thread count value (json-int) - - "cpu-throttle-initial" : initial percentage of time guest cpus are - throttled (json-int) - - "cpu-throttle-increment" : throttle increasing percentage for - auto-converge (json-int) - - "max-bandwidth" : maximium migration speed in bytes per second - (json-int) - - "downtime-limit" : maximum tolerated downtime of migration in - milliseconds (json-int) -Arguments: - -Example: - --> { "execute": "query-migrate-parameters" } -<- { - "return": { - "decompress-threads": 2, - "cpu-throttle-increment": 10, - "compress-threads": 8, - "compress-level": 1, - "cpu-throttle-initial": 20, - "max-bandwidth": 33554432, - "downtime-limit": 300 - } - } - -query-balloon -------------- - -Show balloon information. - -Make an asynchronous request for balloon info. When the request completes a -json-object will be returned containing the following data: - -- "actual": current balloon value in bytes (json-int) - -Example: - --> { "execute": "query-balloon" } -<- { - "return":{ - "actual":1073741824, - } - } - query-tpm --------- @@ -3529,6 +1986,7 @@ Example (1): "policy": "bind" }, { + "id": "mem1", "size": 536870912, "merge": false, "dump": true,