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 time relative to the Epoch 100# 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 time to the given value, 121# then sets the Hardware Clock to the current System Time. 122# This will make it easier for a guest to resynchronize 123# without waiting for NTP. 124# 125# @time: time of nanoseconds, relative to the Epoch of 126# 1970-01-01 in UTC. 127# 128# Returns: Nothing on success. 129# 130# Since: 1.5 131## 132{ 'command': 'guest-set-time', 133 'data': { 'time': 'int' } } 134 135## 136# @GuestAgentCommandInfo: 137# 138# Information about guest agent commands. 139# 140# @name: name of the command 141# 142# @enabled: whether command is currently enabled by guest admin 143# 144# Since 1.1.0 145## 146{ 'type': 'GuestAgentCommandInfo', 147 'data': { 'name': 'str', 'enabled': 'bool' } } 148 149## 150# @GuestAgentInfo 151# 152# Information about guest agent. 153# 154# @version: guest agent version 155# 156# @supported_commands: Information about guest agent commands 157# 158# Since 0.15.0 159## 160{ 'type': 'GuestAgentInfo', 161 'data': { 'version': 'str', 162 'supported_commands': ['GuestAgentCommandInfo'] } } 163## 164# @guest-info: 165# 166# Get some information about the guest agent. 167# 168# Returns: @GuestAgentInfo 169# 170# Since: 0.15.0 171## 172{ 'command': 'guest-info', 173 'returns': 'GuestAgentInfo' } 174 175## 176# @guest-shutdown: 177# 178# Initiate guest-activated shutdown. Note: this is an asynchronous 179# shutdown request, with no guarantee of successful shutdown. 180# 181# @mode: #optional "halt", "powerdown" (default), or "reboot" 182# 183# This command does NOT return a response on success. Success condition 184# is indicated by the VM exiting with a zero exit status or, when 185# running with --no-shutdown, by issuing the query-status QMP command 186# to confirm the VM status is "shutdown". 187# 188# Since: 0.15.0 189## 190{ 'command': 'guest-shutdown', 'data': { '*mode': 'str' }, 191 'success-response': 'no' } 192 193## 194# @guest-file-open: 195# 196# Open a file in the guest and retrieve a file handle for it 197# 198# @filepath: Full path to the file in the guest to open. 199# 200# @mode: #optional open mode, as per fopen(), "r" is the default. 201# 202# Returns: Guest file handle on success. 203# 204# Since: 0.15.0 205## 206{ 'command': 'guest-file-open', 207 'data': { 'path': 'str', '*mode': 'str' }, 208 'returns': 'int' } 209 210## 211# @guest-file-close: 212# 213# Close an open file in the guest 214# 215# @handle: filehandle returned by guest-file-open 216# 217# Returns: Nothing on success. 218# 219# Since: 0.15.0 220## 221{ 'command': 'guest-file-close', 222 'data': { 'handle': 'int' } } 223 224## 225# @GuestFileRead 226# 227# Result of guest agent file-read operation 228# 229# @count: number of bytes read (note: count is *before* 230# base64-encoding is applied) 231# 232# @buf-b64: base64-encoded bytes read 233# 234# @eof: whether EOF was encountered during read operation. 235# 236# Since: 0.15.0 237## 238{ 'type': 'GuestFileRead', 239 'data': { 'count': 'int', 'buf-b64': 'str', 'eof': 'bool' } } 240 241## 242# @guest-file-read: 243# 244# Read from an open file in the guest. Data will be base64-encoded 245# 246# @handle: filehandle returned by guest-file-open 247# 248# @count: #optional maximum number of bytes to read (default is 4KB) 249# 250# Returns: @GuestFileRead on success. 251# 252# Since: 0.15.0 253## 254{ 'command': 'guest-file-read', 255 'data': { 'handle': 'int', '*count': 'int' }, 256 'returns': 'GuestFileRead' } 257 258## 259# @GuestFileWrite 260# 261# Result of guest agent file-write operation 262# 263# @count: number of bytes written (note: count is actual bytes 264# written, after base64-decoding of provided buffer) 265# 266# @eof: whether EOF was encountered during write operation. 267# 268# Since: 0.15.0 269## 270{ 'type': 'GuestFileWrite', 271 'data': { 'count': 'int', 'eof': 'bool' } } 272 273## 274# @guest-file-write: 275# 276# Write to an open file in the guest. 277# 278# @handle: filehandle returned by guest-file-open 279# 280# @buf-b64: base64-encoded string representing data to be written 281# 282# @count: #optional bytes to write (actual bytes, after base64-decode), 283# default is all content in buf-b64 buffer after base64 decoding 284# 285# Returns: @GuestFileWrite on success. 286# 287# Since: 0.15.0 288## 289{ 'command': 'guest-file-write', 290 'data': { 'handle': 'int', 'buf-b64': 'str', '*count': 'int' }, 291 'returns': 'GuestFileWrite' } 292 293 294## 295# @GuestFileSeek 296# 297# Result of guest agent file-seek operation 298# 299# @position: current file position 300# 301# @eof: whether EOF was encountered during file seek 302# 303# Since: 0.15.0 304## 305{ 'type': 'GuestFileSeek', 306 'data': { 'position': 'int', 'eof': 'bool' } } 307 308## 309# @guest-file-seek: 310# 311# Seek to a position in the file, as with fseek(), and return the 312# current file position afterward. Also encapsulates ftell()'s 313# functionality, just Set offset=0, whence=SEEK_CUR. 314# 315# @handle: filehandle returned by guest-file-open 316# 317# @offset: bytes to skip over in the file stream 318# 319# @whence: SEEK_SET, SEEK_CUR, or SEEK_END, as with fseek() 320# 321# Returns: @GuestFileSeek on success. 322# 323# Since: 0.15.0 324## 325{ 'command': 'guest-file-seek', 326 'data': { 'handle': 'int', 'offset': 'int', 'whence': 'int' }, 327 'returns': 'GuestFileSeek' } 328 329## 330# @guest-file-flush: 331# 332# Write file changes bufferred in userspace to disk/kernel buffers 333# 334# @handle: filehandle returned by guest-file-open 335# 336# Returns: Nothing on success. 337# 338# Since: 0.15.0 339## 340{ 'command': 'guest-file-flush', 341 'data': { 'handle': 'int' } } 342 343## 344# @GuestFsFreezeStatus 345# 346# An enumeration of filesystem freeze states 347# 348# @thawed: filesystems thawed/unfrozen 349# 350# @frozen: all non-network guest filesystems frozen 351# 352# Since: 0.15.0 353## 354{ 'enum': 'GuestFsfreezeStatus', 355 'data': [ 'thawed', 'frozen' ] } 356 357## 358# @guest-fsfreeze-status: 359# 360# Get guest fsfreeze state. error state indicates 361# 362# Returns: GuestFsfreezeStatus ("thawed", "frozen", etc., as defined below) 363# 364# Note: This may fail to properly report the current state as a result of 365# some other guest processes having issued an fs freeze/thaw. 366# 367# Since: 0.15.0 368## 369{ 'command': 'guest-fsfreeze-status', 370 'returns': 'GuestFsfreezeStatus' } 371 372## 373# @guest-fsfreeze-freeze: 374# 375# Sync and freeze all freezable, local guest filesystems 376# 377# Returns: Number of file systems currently frozen. On error, all filesystems 378# will be thawed. 379# 380# Since: 0.15.0 381## 382{ 'command': 'guest-fsfreeze-freeze', 383 'returns': 'int' } 384 385## 386# @guest-fsfreeze-thaw: 387# 388# Unfreeze all frozen guest filesystems 389# 390# Returns: Number of file systems thawed by this call 391# 392# Note: if return value does not match the previous call to 393# guest-fsfreeze-freeze, this likely means some freezable 394# filesystems were unfrozen before this call, and that the 395# filesystem state may have changed before issuing this 396# command. 397# 398# Since: 0.15.0 399## 400{ 'command': 'guest-fsfreeze-thaw', 401 'returns': 'int' } 402 403## 404# @guest-fstrim: 405# 406# Discard (or "trim") blocks which are not in use by the filesystem. 407# 408# @minimum: 409# Minimum contiguous free range to discard, in bytes. Free ranges 410# smaller than this may be ignored (this is a hint and the guest 411# may not respect it). By increasing this value, the fstrim 412# operation will complete more quickly for filesystems with badly 413# fragmented free space, although not all blocks will be discarded. 414# The default value is zero, meaning "discard every free block". 415# 416# Returns: Nothing. 417# 418# Since: 1.2 419## 420{ 'command': 'guest-fstrim', 421 'data': { '*minimum': 'int' } } 422 423## 424# @guest-suspend-disk 425# 426# Suspend guest to disk. 427# 428# This command tries to execute the scripts provided by the pm-utils package. 429# If it's not available, the suspend operation will be performed by manually 430# writing to a sysfs file. 431# 432# For the best results it's strongly recommended to have the pm-utils 433# package installed in the guest. 434# 435# This command does NOT return a response on success. There is a high chance 436# the command succeeded if the VM exits with a zero exit status or, when 437# running with --no-shutdown, by issuing the query-status QMP command to 438# to confirm the VM status is "shutdown". However, the VM could also exit 439# (or set its status to "shutdown") due to other reasons. 440# 441# The following errors may be returned: 442# If suspend to disk is not supported, Unsupported 443# 444# Notes: It's strongly recommended to issue the guest-sync command before 445# sending commands when the guest resumes 446# 447# Since: 1.1 448## 449{ 'command': 'guest-suspend-disk', 'success-response': 'no' } 450 451## 452# @guest-suspend-ram 453# 454# Suspend guest to ram. 455# 456# This command tries to execute the scripts provided by the pm-utils package. 457# If it's not available, the suspend operation will be performed by manually 458# writing to a sysfs file. 459# 460# For the best results it's strongly recommended to have the pm-utils 461# package installed in the guest. 462# 463# IMPORTANT: guest-suspend-ram requires QEMU to support the 'system_wakeup' 464# command. Thus, it's *required* to query QEMU for the presence of the 465# 'system_wakeup' command before issuing guest-suspend-ram. 466# 467# This command does NOT return a response on success. There are two options 468# to check for success: 469# 1. Wait for the SUSPEND QMP event from QEMU 470# 2. Issue the query-status QMP command to confirm the VM status is 471# "suspended" 472# 473# The following errors may be returned: 474# If suspend to ram is not supported, Unsupported 475# 476# Notes: It's strongly recommended to issue the guest-sync command before 477# sending commands when the guest resumes 478# 479# Since: 1.1 480## 481{ 'command': 'guest-suspend-ram', 'success-response': 'no' } 482 483## 484# @guest-suspend-hybrid 485# 486# Save guest state to disk and suspend to ram. 487# 488# This command requires the pm-utils package to be installed in the guest. 489# 490# IMPORTANT: guest-suspend-hybrid requires QEMU to support the 'system_wakeup' 491# command. Thus, it's *required* to query QEMU for the presence of the 492# 'system_wakeup' command before issuing guest-suspend-hybrid. 493# 494# This command does NOT return a response on success. There are two options 495# to check for success: 496# 1. Wait for the SUSPEND QMP event from QEMU 497# 2. Issue the query-status QMP command to confirm the VM status is 498# "suspended" 499# 500# The following errors may be returned: 501# If hybrid suspend is not supported, Unsupported 502# 503# Notes: It's strongly recommended to issue the guest-sync command before 504# sending commands when the guest resumes 505# 506# Since: 1.1 507## 508{ 'command': 'guest-suspend-hybrid', 'success-response': 'no' } 509 510## 511# @GuestIpAddressType: 512# 513# An enumeration of supported IP address types 514# 515# @ipv4: IP version 4 516# 517# @ipv6: IP version 6 518# 519# Since: 1.1 520## 521{ 'enum': 'GuestIpAddressType', 522 'data': [ 'ipv4', 'ipv6' ] } 523 524## 525# @GuestIpAddress: 526# 527# @ip-address: IP address 528# 529# @ip-address-type: Type of @ip-address (e.g. ipv4, ipv6) 530# 531# @prefix: Network prefix length of @ip-address 532# 533# Since: 1.1 534## 535{ 'type': 'GuestIpAddress', 536 'data': {'ip-address': 'str', 537 'ip-address-type': 'GuestIpAddressType', 538 'prefix': 'int'} } 539 540## 541# @GuestNetworkInterface: 542# 543# @name: The name of interface for which info are being delivered 544# 545# @hardware-address: Hardware address of @name 546# 547# @ip-addresses: List of addresses assigned to @name 548# 549# Since: 1.1 550## 551{ 'type': 'GuestNetworkInterface', 552 'data': {'name': 'str', 553 '*hardware-address': 'str', 554 '*ip-addresses': ['GuestIpAddress'] } } 555 556## 557# @guest-network-get-interfaces: 558# 559# Get list of guest IP addresses, MAC addresses 560# and netmasks. 561# 562# Returns: List of GuestNetworkInfo on success. 563# 564# Since: 1.1 565## 566{ 'command': 'guest-network-get-interfaces', 567 'returns': ['GuestNetworkInterface'] } 568 569## 570# @GuestLogicalProcessor: 571# 572# @logical-id: Arbitrary guest-specific unique identifier of the VCPU. 573# 574# @online: Whether the VCPU is enabled. 575# 576# @can-offline: #optional Whether offlining the VCPU is possible. This member 577# is always filled in by the guest agent when the structure is 578# returned, and always ignored on input (hence it can be omitted 579# then). 580# 581# Since: 1.5 582## 583{ 'type': 'GuestLogicalProcessor', 584 'data': {'logical-id': 'int', 585 'online': 'bool', 586 '*can-offline': 'bool'} } 587 588## 589# @guest-get-vcpus: 590# 591# Retrieve the list of the guest's logical processors. 592# 593# This is a read-only operation. 594# 595# Returns: The list of all VCPUs the guest knows about. Each VCPU is put on the 596# list exactly once, but their order is unspecified. 597# 598# Since: 1.5 599## 600{ 'command': 'guest-get-vcpus', 601 'returns': ['GuestLogicalProcessor'] } 602 603## 604# @guest-set-vcpus: 605# 606# Attempt to reconfigure (currently: enable/disable) logical processors inside 607# the guest. 608# 609# The input list is processed node by node in order. In each node @logical-id 610# is used to look up the guest VCPU, for which @online specifies the requested 611# state. The set of distinct @logical-id's is only required to be a subset of 612# the guest-supported identifiers. There's no restriction on list length or on 613# repeating the same @logical-id (with possibly different @online field). 614# Preferably the input list should describe a modified subset of 615# @guest-get-vcpus' return value. 616# 617# Returns: The length of the initial sublist that has been successfully 618# processed. The guest agent maximizes this value. Possible cases: 619# 620# 0: if the @vcpus list was empty on input. Guest state 621# has not been changed. Otherwise, 622# 623# Error: processing the first node of @vcpus failed for the 624# reason returned. Guest state has not been changed. 625# Otherwise, 626# 627# < length(@vcpus): more than zero initial nodes have been processed, 628# but not the entire @vcpus list. Guest state has 629# changed accordingly. To retrieve the error 630# (assuming it persists), repeat the call with the 631# successfully processed initial sublist removed. 632# Otherwise, 633# 634# length(@vcpus): call successful. 635# 636# Since: 1.5 637## 638{ 'command': 'guest-set-vcpus', 639 'data': {'vcpus': ['GuestLogicalProcessor'] }, 640 'returns': 'int' } 641