1# *-*- Mode: Python -*-* 2 3## 4# 5# General note concerning the use of guest agent interfaces: 6# 7# "unsupported" is a higher-level error than the errors that individual 8# commands might document. The caller should always be prepared to receive 9# QERR_UNSUPPORTED, even if the given command doesn't specify it, or doesn't 10# document any failure mode at all. 11# 12## 13 14## 15# 16# Echo back a unique integer value, and prepend to response a 17# leading sentinel byte (0xFF) the client can check scan for. 18# 19# This is used by clients talking to the guest agent over the 20# wire to ensure the stream is in sync and doesn't contain stale 21# data from previous client. It must be issued upon initial 22# connection, and after any client-side timeouts (including 23# timeouts on receiving a response to this command). 24# 25# After issuing this request, all guest agent responses should be 26# ignored until the response containing the unique integer value 27# the client passed in is returned. Receival of the 0xFF sentinel 28# byte must be handled as an indication that the client's 29# lexer/tokenizer/parser state should be flushed/reset in 30# preparation for reliably receiving the subsequent response. As 31# an optimization, clients may opt to ignore all data until a 32# sentinel value is receiving to avoid unnecessary processing of 33# stale data. 34# 35# Similarly, clients should also precede this *request* 36# with a 0xFF byte to make sure the guest agent flushes any 37# partially read JSON data from a previous client connection. 38# 39# @id: randomly generated 64-bit integer 40# 41# Returns: The unique integer id passed in by the client 42# 43# Since: 1.1 44# ## 45{ 'command': 'guest-sync-delimited', 46 'data': { 'id': 'int' }, 47 'returns': 'int' } 48 49## 50# @guest-sync: 51# 52# Echo back a unique integer value 53# 54# This is used by clients talking to the guest agent over the 55# wire to ensure the stream is in sync and doesn't contain stale 56# data from previous client. All guest agent responses should be 57# ignored until the provided unique integer value is returned, 58# and it is up to the client to handle stale whole or 59# partially-delivered JSON text in such a way that this response 60# can be obtained. 61# 62# In cases where a partial stale response was previously 63# received by the client, this cannot always be done reliably. 64# One particular scenario being if qemu-ga responses are fed 65# character-by-character into a JSON parser. In these situations, 66# using guest-sync-delimited may be optimal. 67# 68# For clients that fetch responses line by line and convert them 69# to JSON objects, guest-sync should be sufficient, but note that 70# in cases where the channel is dirty some attempts at parsing the 71# response may result in a parser error. 72# 73# Such clients should also precede this command 74# with a 0xFF byte to make sure the guest agent flushes any 75# partially read JSON data from a previous session. 76# 77# @id: randomly generated 64-bit integer 78# 79# Returns: The unique integer id passed in by the client 80# 81# Since: 0.15.0 82## 83{ 'command': 'guest-sync', 84 'data': { 'id': 'int' }, 85 'returns': 'int' } 86 87## 88# @guest-ping: 89# 90# Ping the guest agent, a non-error return implies success 91# 92# Since: 0.15.0 93## 94{ 'command': 'guest-ping' } 95 96## 97# @guest-get-time: 98# 99# Get the information about guest's System Time relative to 100# the Epoch of 1970-01-01 in UTC. 101# 102# Returns: Time in nanoseconds. 103# 104# Since 1.5 105## 106{ 'command': 'guest-get-time', 107 'returns': 'int' } 108 109## 110# @guest-set-time: 111# 112# Set guest time. 113# 114# When a guest is paused or migrated to a file then loaded 115# from that file, the guest OS has no idea that there 116# was a big gap in the time. Depending on how long the 117# gap was, NTP might not be able to resynchronize the 118# guest. 119# 120# This command tries to set guest's System Time to the 121# given value, then sets the Hardware Clock (RTC) to the 122# current System Time. This will make it easier for a guest 123# to resynchronize without waiting for NTP. If no @time is 124# specified, then the time to set is read from RTC. However, 125# this may not be supported on all platforms (i.e. Windows). 126# If that's the case users are advised to always pass a 127# value. 128# 129# @time: #optional time of nanoseconds, relative to the Epoch 130# of 1970-01-01 in UTC. 131# 132# Returns: Nothing on success. 133# 134# Since: 1.5 135## 136{ 'command': 'guest-set-time', 137 'data': { '*time': 'int' } } 138 139## 140# @GuestAgentCommandInfo: 141# 142# Information about guest agent commands. 143# 144# @name: name of the command 145# 146# @enabled: whether command is currently enabled by guest admin 147# 148# @success-response: whether command returns a response on success 149# (since 1.7) 150# 151# Since 1.1.0 152## 153{ 'struct': 'GuestAgentCommandInfo', 154 'data': { 'name': 'str', 'enabled': 'bool', 'success-response': 'bool' } } 155 156## 157# @GuestAgentInfo 158# 159# Information about guest agent. 160# 161# @version: guest agent version 162# 163# @supported_commands: Information about guest agent commands 164# 165# Since 0.15.0 166## 167{ 'struct': 'GuestAgentInfo', 168 'data': { 'version': 'str', 169 'supported_commands': ['GuestAgentCommandInfo'] } } 170## 171# @guest-info: 172# 173# Get some information about the guest agent. 174# 175# Returns: @GuestAgentInfo 176# 177# Since: 0.15.0 178## 179{ 'command': 'guest-info', 180 'returns': 'GuestAgentInfo' } 181 182## 183# @guest-shutdown: 184# 185# Initiate guest-activated shutdown. Note: this is an asynchronous 186# shutdown request, with no guarantee of successful shutdown. 187# 188# @mode: #optional "halt", "powerdown" (default), or "reboot" 189# 190# This command does NOT return a response on success. Success condition 191# is indicated by the VM exiting with a zero exit status or, when 192# running with --no-shutdown, by issuing the query-status QMP command 193# to confirm the VM status is "shutdown". 194# 195# Since: 0.15.0 196## 197{ 'command': 'guest-shutdown', 'data': { '*mode': 'str' }, 198 'success-response': false } 199 200## 201# @guest-file-open: 202# 203# Open a file in the guest and retrieve a file handle for it 204# 205# @filepath: Full path to the file in the guest to open. 206# 207# @mode: #optional open mode, as per fopen(), "r" is the default. 208# 209# Returns: Guest file handle on success. 210# 211# Since: 0.15.0 212## 213{ 'command': 'guest-file-open', 214 'data': { 'path': 'str', '*mode': 'str' }, 215 'returns': 'int' } 216 217## 218# @guest-file-close: 219# 220# Close an open file in the guest 221# 222# @handle: filehandle returned by guest-file-open 223# 224# Returns: Nothing on success. 225# 226# Since: 0.15.0 227## 228{ 'command': 'guest-file-close', 229 'data': { 'handle': 'int' } } 230 231## 232# @GuestFileRead 233# 234# Result of guest agent file-read operation 235# 236# @count: number of bytes read (note: count is *before* 237# base64-encoding is applied) 238# 239# @buf-b64: base64-encoded bytes read 240# 241# @eof: whether EOF was encountered during read operation. 242# 243# Since: 0.15.0 244## 245{ 'struct': 'GuestFileRead', 246 'data': { 'count': 'int', 'buf-b64': 'str', 'eof': 'bool' } } 247 248## 249# @guest-file-read: 250# 251# Read from an open file in the guest. Data will be base64-encoded 252# 253# @handle: filehandle returned by guest-file-open 254# 255# @count: #optional maximum number of bytes to read (default is 4KB) 256# 257# Returns: @GuestFileRead on success. 258# 259# Since: 0.15.0 260## 261{ 'command': 'guest-file-read', 262 'data': { 'handle': 'int', '*count': 'int' }, 263 'returns': 'GuestFileRead' } 264 265## 266# @GuestFileWrite 267# 268# Result of guest agent file-write operation 269# 270# @count: number of bytes written (note: count is actual bytes 271# written, after base64-decoding of provided buffer) 272# 273# @eof: whether EOF was encountered during write operation. 274# 275# Since: 0.15.0 276## 277{ 'struct': 'GuestFileWrite', 278 'data': { 'count': 'int', 'eof': 'bool' } } 279 280## 281# @guest-file-write: 282# 283# Write to an open file in the guest. 284# 285# @handle: filehandle returned by guest-file-open 286# 287# @buf-b64: base64-encoded string representing data to be written 288# 289# @count: #optional bytes to write (actual bytes, after base64-decode), 290# default is all content in buf-b64 buffer after base64 decoding 291# 292# Returns: @GuestFileWrite on success. 293# 294# Since: 0.15.0 295## 296{ 'command': 'guest-file-write', 297 'data': { 'handle': 'int', 'buf-b64': 'str', '*count': 'int' }, 298 'returns': 'GuestFileWrite' } 299 300 301## 302# @GuestFileSeek 303# 304# Result of guest agent file-seek operation 305# 306# @position: current file position 307# 308# @eof: whether EOF was encountered during file seek 309# 310# Since: 0.15.0 311## 312{ 'struct': 'GuestFileSeek', 313 'data': { 'position': 'int', 'eof': 'bool' } } 314 315## 316# @guest-file-seek: 317# 318# Seek to a position in the file, as with fseek(), and return the 319# current file position afterward. Also encapsulates ftell()'s 320# functionality, just Set offset=0, whence=SEEK_CUR. 321# 322# @handle: filehandle returned by guest-file-open 323# 324# @offset: bytes to skip over in the file stream 325# 326# @whence: SEEK_SET, SEEK_CUR, or SEEK_END, as with fseek() 327# 328# Returns: @GuestFileSeek on success. 329# 330# Since: 0.15.0 331## 332{ 'command': 'guest-file-seek', 333 'data': { 'handle': 'int', 'offset': 'int', 'whence': 'int' }, 334 'returns': 'GuestFileSeek' } 335 336## 337# @guest-file-flush: 338# 339# Write file changes bufferred in userspace to disk/kernel buffers 340# 341# @handle: filehandle returned by guest-file-open 342# 343# Returns: Nothing on success. 344# 345# Since: 0.15.0 346## 347{ 'command': 'guest-file-flush', 348 'data': { 'handle': 'int' } } 349 350## 351# @GuestFsFreezeStatus 352# 353# An enumeration of filesystem freeze states 354# 355# @thawed: filesystems thawed/unfrozen 356# 357# @frozen: all non-network guest filesystems frozen 358# 359# Since: 0.15.0 360## 361{ 'enum': 'GuestFsfreezeStatus', 362 'data': [ 'thawed', 'frozen' ] } 363 364## 365# @guest-fsfreeze-status: 366# 367# Get guest fsfreeze state. error state indicates 368# 369# Returns: GuestFsfreezeStatus ("thawed", "frozen", etc., as defined below) 370# 371# Note: This may fail to properly report the current state as a result of 372# some other guest processes having issued an fs freeze/thaw. 373# 374# Since: 0.15.0 375## 376{ 'command': 'guest-fsfreeze-status', 377 'returns': 'GuestFsfreezeStatus' } 378 379## 380# @guest-fsfreeze-freeze: 381# 382# Sync and freeze all freezable, local guest filesystems 383# 384# Returns: Number of file systems currently frozen. On error, all filesystems 385# will be thawed. 386# 387# Since: 0.15.0 388## 389{ 'command': 'guest-fsfreeze-freeze', 390 'returns': 'int' } 391 392## 393# @guest-fsfreeze-freeze-list: 394# 395# Sync and freeze specified guest filesystems 396# 397# @mountpoints: #optional an array of mountpoints of filesystems to be frozen. 398# If omitted, every mounted filesystem is frozen. 399# 400# Returns: Number of file systems currently frozen. On error, all filesystems 401# will be thawed. 402# 403# Since: 2.2 404## 405{ 'command': 'guest-fsfreeze-freeze-list', 406 'data': { '*mountpoints': ['str'] }, 407 'returns': 'int' } 408 409## 410# @guest-fsfreeze-thaw: 411# 412# Unfreeze all frozen guest filesystems 413# 414# Returns: Number of file systems thawed by this call 415# 416# Note: if return value does not match the previous call to 417# guest-fsfreeze-freeze, this likely means some freezable 418# filesystems were unfrozen before this call, and that the 419# filesystem state may have changed before issuing this 420# command. 421# 422# Since: 0.15.0 423## 424{ 'command': 'guest-fsfreeze-thaw', 425 'returns': 'int' } 426 427## 428# @GuestFilesystemTrimResult 429# 430# @path: path that was trimmed 431# @error: an error message when trim failed 432# @trimmed: bytes trimmed for this path 433# @minimum: reported effective minimum for this path 434# 435# Since: 2.4 436## 437{ 'struct': 'GuestFilesystemTrimResult', 438 'data': {'path': 'str', 439 '*trimmed': 'int', '*minimum': 'int', '*error': 'str'} } 440 441## 442# @GuestFilesystemTrimResponse 443# 444# @paths: list of @GuestFilesystemTrimResult per path that was trimmed 445# 446# Since: 2.4 447## 448{ 'struct': 'GuestFilesystemTrimResponse', 449 'data': {'paths': ['GuestFilesystemTrimResult']} } 450 451## 452# @guest-fstrim: 453# 454# Discard (or "trim") blocks which are not in use by the filesystem. 455# 456# @minimum: 457# Minimum contiguous free range to discard, in bytes. Free ranges 458# smaller than this may be ignored (this is a hint and the guest 459# may not respect it). By increasing this value, the fstrim 460# operation will complete more quickly for filesystems with badly 461# fragmented free space, although not all blocks will be discarded. 462# The default value is zero, meaning "discard every free block". 463# 464# Returns: A @GuestFilesystemTrimResponse which contains the 465# status of all trimmed paths. (since 2.4) 466# 467# Since: 1.2 468## 469{ 'command': 'guest-fstrim', 470 'data': { '*minimum': 'int' }, 471 'returns': 'GuestFilesystemTrimResponse' } 472 473## 474# @guest-suspend-disk 475# 476# Suspend guest to disk. 477# 478# This command tries to execute the scripts provided by the pm-utils package. 479# If it's not available, the suspend operation will be performed by manually 480# writing to a sysfs file. 481# 482# For the best results it's strongly recommended to have the pm-utils 483# package installed in the guest. 484# 485# This command does NOT return a response on success. There is a high chance 486# the command succeeded if the VM exits with a zero exit status or, when 487# running with --no-shutdown, by issuing the query-status QMP command to 488# to confirm the VM status is "shutdown". However, the VM could also exit 489# (or set its status to "shutdown") due to other reasons. 490# 491# The following errors may be returned: 492# If suspend to disk is not supported, Unsupported 493# 494# Notes: It's strongly recommended to issue the guest-sync command before 495# sending commands when the guest resumes 496# 497# Since: 1.1 498## 499{ 'command': 'guest-suspend-disk', 'success-response': false } 500 501## 502# @guest-suspend-ram 503# 504# Suspend guest to ram. 505# 506# This command tries to execute the scripts provided by the pm-utils package. 507# If it's not available, the suspend operation will be performed by manually 508# writing to a sysfs file. 509# 510# For the best results it's strongly recommended to have the pm-utils 511# package installed in the guest. 512# 513# IMPORTANT: guest-suspend-ram requires QEMU to support the 'system_wakeup' 514# command. Thus, it's *required* to query QEMU for the presence of the 515# 'system_wakeup' command before issuing guest-suspend-ram. 516# 517# This command does NOT return a response on success. There are two options 518# to check for success: 519# 1. Wait for the SUSPEND QMP event from QEMU 520# 2. Issue the query-status QMP command to confirm the VM status is 521# "suspended" 522# 523# The following errors may be returned: 524# If suspend to ram is not supported, Unsupported 525# 526# Notes: It's strongly recommended to issue the guest-sync command before 527# sending commands when the guest resumes 528# 529# Since: 1.1 530## 531{ 'command': 'guest-suspend-ram', 'success-response': false } 532 533## 534# @guest-suspend-hybrid 535# 536# Save guest state to disk and suspend to ram. 537# 538# This command requires the pm-utils package to be installed in the guest. 539# 540# IMPORTANT: guest-suspend-hybrid requires QEMU to support the 'system_wakeup' 541# command. Thus, it's *required* to query QEMU for the presence of the 542# 'system_wakeup' command before issuing guest-suspend-hybrid. 543# 544# This command does NOT return a response on success. There are two options 545# to check for success: 546# 1. Wait for the SUSPEND QMP event from QEMU 547# 2. Issue the query-status QMP command to confirm the VM status is 548# "suspended" 549# 550# The following errors may be returned: 551# If hybrid suspend is not supported, Unsupported 552# 553# Notes: It's strongly recommended to issue the guest-sync command before 554# sending commands when the guest resumes 555# 556# Since: 1.1 557## 558{ 'command': 'guest-suspend-hybrid', 'success-response': false } 559 560## 561# @GuestIpAddressType: 562# 563# An enumeration of supported IP address types 564# 565# @ipv4: IP version 4 566# 567# @ipv6: IP version 6 568# 569# Since: 1.1 570## 571{ 'enum': 'GuestIpAddressType', 572 'data': [ 'ipv4', 'ipv6' ] } 573 574## 575# @GuestIpAddress: 576# 577# @ip-address: IP address 578# 579# @ip-address-type: Type of @ip-address (e.g. ipv4, ipv6) 580# 581# @prefix: Network prefix length of @ip-address 582# 583# Since: 1.1 584## 585{ 'struct': 'GuestIpAddress', 586 'data': {'ip-address': 'str', 587 'ip-address-type': 'GuestIpAddressType', 588 'prefix': 'int'} } 589 590## 591# @GuestNetworkInterface: 592# 593# @name: The name of interface for which info are being delivered 594# 595# @hardware-address: Hardware address of @name 596# 597# @ip-addresses: List of addresses assigned to @name 598# 599# Since: 1.1 600## 601{ 'struct': 'GuestNetworkInterface', 602 'data': {'name': 'str', 603 '*hardware-address': 'str', 604 '*ip-addresses': ['GuestIpAddress'] } } 605 606## 607# @guest-network-get-interfaces: 608# 609# Get list of guest IP addresses, MAC addresses 610# and netmasks. 611# 612# Returns: List of GuestNetworkInfo on success. 613# 614# Since: 1.1 615## 616{ 'command': 'guest-network-get-interfaces', 617 'returns': ['GuestNetworkInterface'] } 618 619## 620# @GuestLogicalProcessor: 621# 622# @logical-id: Arbitrary guest-specific unique identifier of the VCPU. 623# 624# @online: Whether the VCPU is enabled. 625# 626# @can-offline: #optional Whether offlining the VCPU is possible. This member 627# is always filled in by the guest agent when the structure is 628# returned, and always ignored on input (hence it can be omitted 629# then). 630# 631# Since: 1.5 632## 633{ 'struct': 'GuestLogicalProcessor', 634 'data': {'logical-id': 'int', 635 'online': 'bool', 636 '*can-offline': 'bool'} } 637 638## 639# @guest-get-vcpus: 640# 641# Retrieve the list of the guest's logical processors. 642# 643# This is a read-only operation. 644# 645# Returns: The list of all VCPUs the guest knows about. Each VCPU is put on the 646# list exactly once, but their order is unspecified. 647# 648# Since: 1.5 649## 650{ 'command': 'guest-get-vcpus', 651 'returns': ['GuestLogicalProcessor'] } 652 653## 654# @guest-set-vcpus: 655# 656# Attempt to reconfigure (currently: enable/disable) logical processors inside 657# the guest. 658# 659# The input list is processed node by node in order. In each node @logical-id 660# is used to look up the guest VCPU, for which @online specifies the requested 661# state. The set of distinct @logical-id's is only required to be a subset of 662# the guest-supported identifiers. There's no restriction on list length or on 663# repeating the same @logical-id (with possibly different @online field). 664# Preferably the input list should describe a modified subset of 665# @guest-get-vcpus' return value. 666# 667# Returns: The length of the initial sublist that has been successfully 668# processed. The guest agent maximizes this value. Possible cases: 669# 670# 0: if the @vcpus list was empty on input. Guest state 671# has not been changed. Otherwise, 672# 673# Error: processing the first node of @vcpus failed for the 674# reason returned. Guest state has not been changed. 675# Otherwise, 676# 677# < length(@vcpus): more than zero initial nodes have been processed, 678# but not the entire @vcpus list. Guest state has 679# changed accordingly. To retrieve the error 680# (assuming it persists), repeat the call with the 681# successfully processed initial sublist removed. 682# Otherwise, 683# 684# length(@vcpus): call successful. 685# 686# Since: 1.5 687## 688{ 'command': 'guest-set-vcpus', 689 'data': {'vcpus': ['GuestLogicalProcessor'] }, 690 'returns': 'int' } 691 692## 693# @GuestDiskBusType 694# 695# An enumeration of bus type of disks 696# 697# @ide: IDE disks 698# @fdc: floppy disks 699# @scsi: SCSI disks 700# @virtio: virtio disks 701# @xen: Xen disks 702# @usb: USB disks 703# @uml: UML disks 704# @sata: SATA disks 705# @sd: SD cards 706# @unknown: Unknown bus type 707# @ieee1394: Win IEEE 1394 bus type 708# @ssa: Win SSA bus type 709# @fibre: Win fiber channel bus type 710# @raid: Win RAID bus type 711# @iscsi: Win iScsi bus type 712# @sas: Win serial-attaches SCSI bus type 713# @mmc: Win multimedia card (MMC) bus type 714# @virtual: Win virtual bus type 715# @file-backed virtual: Win file-backed bus type 716# 717# Since: 2.2; 'Unknown' and all entries below since 2.4 718## 719{ 'enum': 'GuestDiskBusType', 720 'data': [ 'ide', 'fdc', 'scsi', 'virtio', 'xen', 'usb', 'uml', 'sata', 721 'sd', 'unknown', 'ieee1394', 'ssa', 'fibre', 'raid', 'iscsi', 722 'sas', 'mmc', 'virtual', 'file-backed-virtual' ] } 723 724 725## 726# @GuestPCIAddress: 727# 728# @domain: domain id 729# @bus: bus id 730# @slot: slot id 731# @function: function id 732# 733# Since: 2.2 734## 735{ 'struct': 'GuestPCIAddress', 736 'data': {'domain': 'int', 'bus': 'int', 737 'slot': 'int', 'function': 'int'} } 738 739## 740# @GuestDiskAddress: 741# 742# @pci-controller: controller's PCI address 743# @type: bus type 744# @bus: bus id 745# @target: target id 746# @unit: unit id 747# 748# Since: 2.2 749## 750{ 'struct': 'GuestDiskAddress', 751 'data': {'pci-controller': 'GuestPCIAddress', 752 'bus-type': 'GuestDiskBusType', 753 'bus': 'int', 'target': 'int', 'unit': 'int'} } 754 755## 756# @GuestFilesystemInfo 757# 758# @name: disk name 759# @mountpoint: mount point path 760# @type: file system type string 761# @disk: an array of disk hardware information that the volume lies on, 762# which may be empty if the disk type is not supported 763# 764# Since: 2.2 765## 766{ 'struct': 'GuestFilesystemInfo', 767 'data': {'name': 'str', 'mountpoint': 'str', 'type': 'str', 768 'disk': ['GuestDiskAddress']} } 769 770## 771# @guest-get-fsinfo: 772# 773# Returns: The list of filesystems information mounted in the guest. 774# The returned mountpoints may be specified to 775# @guest-fsfreeze-freeze-list. 776# Network filesystems (such as CIFS and NFS) are not listed. 777# 778# Since: 2.2 779## 780{ 'command': 'guest-get-fsinfo', 781 'returns': ['GuestFilesystemInfo'] } 782 783## 784# @guest-set-user-password 785# 786# @username: the user account whose password to change 787# @password: the new password entry string, base64 encoded 788# @crypted: true if password is already crypt()d, false if raw 789# 790# If the @crypted flag is true, it is the caller's responsibility 791# to ensure the correct crypt() encryption scheme is used. This 792# command does not attempt to interpret or report on the encryption 793# scheme. Refer to the documentation of the guest operating system 794# in question to determine what is supported. 795# 796# Note all guest operating systems will support use of the 797# @crypted flag, as they may require the clear-text password 798# 799# The @password parameter must always be base64 encoded before 800# transmission, even if already crypt()d, to ensure it is 8-bit 801# safe when passed as JSON. 802# 803# Returns: Nothing on success. 804# 805# Since 2.3 806## 807{ 'command': 'guest-set-user-password', 808 'data': { 'username': 'str', 'password': 'str', 'crypted': 'bool' } } 809 810# @GuestMemoryBlock: 811# 812# @phys-index: Arbitrary guest-specific unique identifier of the MEMORY BLOCK. 813# 814# @online: Whether the MEMORY BLOCK is enabled in guest. 815# 816# @can-offline: #optional Whether offlining the MEMORY BLOCK is possible. 817# This member is always filled in by the guest agent when the 818# structure is returned, and always ignored on input (hence it 819# can be omitted then). 820# 821# Since: 2.3 822## 823{ 'struct': 'GuestMemoryBlock', 824 'data': {'phys-index': 'uint64', 825 'online': 'bool', 826 '*can-offline': 'bool'} } 827 828## 829# @guest-get-memory-blocks: 830# 831# Retrieve the list of the guest's memory blocks. 832# 833# This is a read-only operation. 834# 835# Returns: The list of all memory blocks the guest knows about. 836# Each memory block is put on the list exactly once, but their order 837# is unspecified. 838# 839# Since: 2.3 840## 841{ 'command': 'guest-get-memory-blocks', 842 'returns': ['GuestMemoryBlock'] } 843 844## 845# @GuestMemoryBlockResponseType 846# 847# An enumeration of memory block operation result. 848# 849# @success: the operation of online/offline memory block is successful. 850# @not-found: can't find the corresponding memoryXXX directory in sysfs. 851# @operation-not-supported: for some old kernels, it does not support 852# online or offline memory block. 853# @operation-failed: the operation of online/offline memory block fails, 854# because of some errors happen. 855# 856# Since: 2.3 857## 858{ 'enum': 'GuestMemoryBlockResponseType', 859 'data': ['success', 'not-found', 'operation-not-supported', 860 'operation-failed'] } 861 862## 863# @GuestMemoryBlockResponse: 864# 865# @phys-index: same with the 'phys-index' member of @GuestMemoryBlock. 866# 867# @response: the result of memory block operation. 868# 869# @error-code: #optional the error number. 870# When memory block operation fails, we assign the value of 871# 'errno' to this member, it indicates what goes wrong. 872# When the operation succeeds, it will be omitted. 873# 874# Since: 2.3 875## 876{ 'struct': 'GuestMemoryBlockResponse', 877 'data': { 'phys-index': 'uint64', 878 'response': 'GuestMemoryBlockResponseType', 879 '*error-code': 'int' }} 880 881## 882# @guest-set-memory-blocks: 883# 884# Attempt to reconfigure (currently: enable/disable) state of memory blocks 885# inside the guest. 886# 887# The input list is processed node by node in order. In each node @phys-index 888# is used to look up the guest MEMORY BLOCK, for which @online specifies the 889# requested state. The set of distinct @phys-index's is only required to be a 890# subset of the guest-supported identifiers. There's no restriction on list 891# length or on repeating the same @phys-index (with possibly different @online 892# field). 893# Preferably the input list should describe a modified subset of 894# @guest-get-memory-blocks' return value. 895# 896# Returns: The operation results, it is a list of @GuestMemoryBlockResponse, 897# which is corresponding to the input list. 898# 899# Note: it will return NULL if the @mem-blks list was empty on input, 900# or there is an error, and in this case, guest state will not be 901# changed. 902# 903# Since: 2.3 904## 905{ 'command': 'guest-set-memory-blocks', 906 'data': {'mem-blks': ['GuestMemoryBlock'] }, 907 'returns': ['GuestMemoryBlockResponse'] } 908 909# @GuestMemoryBlockInfo: 910# 911# @size: the size (in bytes) of the guest memory blocks, 912# which are the minimal units of memory block online/offline 913# operations (also called Logical Memory Hotplug). 914# 915# Since: 2.3 916## 917{ 'struct': 'GuestMemoryBlockInfo', 918 'data': {'size': 'uint64'} } 919 920## 921# @guest-get-memory-block-info: 922# 923# Get information relating to guest memory blocks. 924# 925# Returns: memory block size in bytes. 926# Returns: @GuestMemoryBlockInfo 927# 928# Since 2.3 929## 930{ 'command': 'guest-get-memory-block-info', 931 'returns': 'GuestMemoryBlockInfo' } 932