xref: /openbmc/qemu/qga/qapi-schema.json (revision 2993683b)
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