]> git.proxmox.com Git - qemu.git/blob - qga/qapi-schema.json
Merge remote-tracking branch 'mst/tags/for_anthony' into staging
[qemu.git] / qga / qapi-schema.json
1 # *-*- Mode: Python -*-*
2
3 ##
4 #
5 # Echo back a unique integer value, and prepend to response a
6 # leading sentinel byte (0xFF) the client can check scan for.
7 #
8 # This is used by clients talking to the guest agent over the
9 # wire to ensure the stream is in sync and doesn't contain stale
10 # data from previous client. It must be issued upon initial
11 # connection, and after any client-side timeouts (including
12 # timeouts on receiving a response to this command).
13 #
14 # After issuing this request, all guest agent responses should be
15 # ignored until the response containing the unique integer value
16 # the client passed in is returned. Receival of the 0xFF sentinel
17 # byte must be handled as an indication that the client's
18 # lexer/tokenizer/parser state should be flushed/reset in
19 # preparation for reliably receiving the subsequent response. As
20 # an optimization, clients may opt to ignore all data until a
21 # sentinel value is receiving to avoid unnecessary processing of
22 # stale data.
23 #
24 # Similarly, clients should also precede this *request*
25 # with a 0xFF byte to make sure the guest agent flushes any
26 # partially read JSON data from a previous client connection.
27 #
28 # @id: randomly generated 64-bit integer
29 #
30 # Returns: The unique integer id passed in by the client
31 #
32 # Since: 1.1
33 # ##
34 { 'command': 'guest-sync-delimited',
35 'data': { 'id': 'int' },
36 'returns': 'int' }
37
38 ##
39 # @guest-sync:
40 #
41 # Echo back a unique integer value
42 #
43 # This is used by clients talking to the guest agent over the
44 # wire to ensure the stream is in sync and doesn't contain stale
45 # data from previous client. All guest agent responses should be
46 # ignored until the provided unique integer value is returned,
47 # and it is up to the client to handle stale whole or
48 # partially-delivered JSON text in such a way that this response
49 # can be obtained.
50 #
51 # In cases where a partial stale response was previously
52 # received by the client, this cannot always be done reliably.
53 # One particular scenario being if qemu-ga responses are fed
54 # character-by-character into a JSON parser. In these situations,
55 # using guest-sync-delimited may be optimal.
56 #
57 # For clients that fetch responses line by line and convert them
58 # to JSON objects, guest-sync should be sufficient, but note that
59 # in cases where the channel is dirty some attempts at parsing the
60 # response may result in a parser error.
61 #
62 # Such clients should also precede this command
63 # with a 0xFF byte to make sure the guest agent flushes any
64 # partially read JSON data from a previous session.
65 #
66 # @id: randomly generated 64-bit integer
67 #
68 # Returns: The unique integer id passed in by the client
69 #
70 # Since: 0.15.0
71 ##
72 { 'command': 'guest-sync',
73 'data': { 'id': 'int' },
74 'returns': 'int' }
75
76 ##
77 # @guest-ping:
78 #
79 # Ping the guest agent, a non-error return implies success
80 #
81 # Since: 0.15.0
82 ##
83 { 'command': 'guest-ping' }
84
85 ##
86 # @guest-get-time:
87 #
88 # Get the information about guest time relative to the Epoch
89 # of 1970-01-01 in UTC.
90 #
91 # Returns: Time in nanoseconds.
92 #
93 # Since 1.5
94 ##
95 { 'command': 'guest-get-time',
96 'returns': 'int' }
97
98 ##
99 # @guest-set-time:
100 #
101 # Set guest time.
102 #
103 # When a guest is paused or migrated to a file then loaded
104 # from that file, the guest OS has no idea that there
105 # was a big gap in the time. Depending on how long the
106 # gap was, NTP might not be able to resynchronize the
107 # guest.
108 #
109 # This command tries to set guest time to the given value,
110 # then sets the Hardware Clock to the current System Time.
111 # This will make it easier for a guest to resynchronize
112 # without waiting for NTP.
113 #
114 # @time: time of nanoseconds, relative to the Epoch of
115 # 1970-01-01 in UTC.
116 #
117 # Returns: Nothing on success.
118 #
119 # Since: 1.5
120 ##
121 { 'command': 'guest-set-time',
122 'data': { 'time': 'int' } }
123
124 ##
125 # @GuestAgentCommandInfo:
126 #
127 # Information about guest agent commands.
128 #
129 # @name: name of the command
130 #
131 # @enabled: whether command is currently enabled by guest admin
132 #
133 # Since 1.1.0
134 ##
135 { 'type': 'GuestAgentCommandInfo',
136 'data': { 'name': 'str', 'enabled': 'bool' } }
137
138 ##
139 # @GuestAgentInfo
140 #
141 # Information about guest agent.
142 #
143 # @version: guest agent version
144 #
145 # @supported_commands: Information about guest agent commands
146 #
147 # Since 0.15.0
148 ##
149 { 'type': 'GuestAgentInfo',
150 'data': { 'version': 'str',
151 'supported_commands': ['GuestAgentCommandInfo'] } }
152 ##
153 # @guest-info:
154 #
155 # Get some information about the guest agent.
156 #
157 # Returns: @GuestAgentInfo
158 #
159 # Since: 0.15.0
160 ##
161 { 'command': 'guest-info',
162 'returns': 'GuestAgentInfo' }
163
164 ##
165 # @guest-shutdown:
166 #
167 # Initiate guest-activated shutdown. Note: this is an asynchronous
168 # shutdown request, with no guarantee of successful shutdown.
169 #
170 # @mode: #optional "halt", "powerdown" (default), or "reboot"
171 #
172 # This command does NOT return a response on success. Success condition
173 # is indicated by the VM exiting with a zero exit status or, when
174 # running with --no-shutdown, by issuing the query-status QMP command
175 # to confirm the VM status is "shutdown".
176 #
177 # Since: 0.15.0
178 ##
179 { 'command': 'guest-shutdown', 'data': { '*mode': 'str' },
180 'success-response': 'no' }
181
182 ##
183 # @guest-file-open:
184 #
185 # Open a file in the guest and retrieve a file handle for it
186 #
187 # @filepath: Full path to the file in the guest to open.
188 #
189 # @mode: #optional open mode, as per fopen(), "r" is the default.
190 #
191 # Returns: Guest file handle on success.
192 #
193 # Since: 0.15.0
194 ##
195 { 'command': 'guest-file-open',
196 'data': { 'path': 'str', '*mode': 'str' },
197 'returns': 'int' }
198
199 ##
200 # @guest-file-close:
201 #
202 # Close an open file in the guest
203 #
204 # @handle: filehandle returned by guest-file-open
205 #
206 # Returns: Nothing on success.
207 #
208 # Since: 0.15.0
209 ##
210 { 'command': 'guest-file-close',
211 'data': { 'handle': 'int' } }
212
213 ##
214 # @GuestFileRead
215 #
216 # Result of guest agent file-read operation
217 #
218 # @count: number of bytes read (note: count is *before*
219 # base64-encoding is applied)
220 #
221 # @buf-b64: base64-encoded bytes read
222 #
223 # @eof: whether EOF was encountered during read operation.
224 #
225 # Since: 0.15.0
226 ##
227 { 'type': 'GuestFileRead',
228 'data': { 'count': 'int', 'buf-b64': 'str', 'eof': 'bool' } }
229
230 ##
231 # @guest-file-read:
232 #
233 # Read from an open file in the guest. Data will be base64-encoded
234 #
235 # @handle: filehandle returned by guest-file-open
236 #
237 # @count: #optional maximum number of bytes to read (default is 4KB)
238 #
239 # Returns: @GuestFileRead on success.
240 #
241 # Since: 0.15.0
242 ##
243 { 'command': 'guest-file-read',
244 'data': { 'handle': 'int', '*count': 'int' },
245 'returns': 'GuestFileRead' }
246
247 ##
248 # @GuestFileWrite
249 #
250 # Result of guest agent file-write operation
251 #
252 # @count: number of bytes written (note: count is actual bytes
253 # written, after base64-decoding of provided buffer)
254 #
255 # @eof: whether EOF was encountered during write operation.
256 #
257 # Since: 0.15.0
258 ##
259 { 'type': 'GuestFileWrite',
260 'data': { 'count': 'int', 'eof': 'bool' } }
261
262 ##
263 # @guest-file-write:
264 #
265 # Write to an open file in the guest.
266 #
267 # @handle: filehandle returned by guest-file-open
268 #
269 # @buf-b64: base64-encoded string representing data to be written
270 #
271 # @count: #optional bytes to write (actual bytes, after base64-decode),
272 # default is all content in buf-b64 buffer after base64 decoding
273 #
274 # Returns: @GuestFileWrite on success.
275 #
276 # Since: 0.15.0
277 ##
278 { 'command': 'guest-file-write',
279 'data': { 'handle': 'int', 'buf-b64': 'str', '*count': 'int' },
280 'returns': 'GuestFileWrite' }
281
282
283 ##
284 # @GuestFileSeek
285 #
286 # Result of guest agent file-seek operation
287 #
288 # @position: current file position
289 #
290 # @eof: whether EOF was encountered during file seek
291 #
292 # Since: 0.15.0
293 ##
294 { 'type': 'GuestFileSeek',
295 'data': { 'position': 'int', 'eof': 'bool' } }
296
297 ##
298 # @guest-file-seek:
299 #
300 # Seek to a position in the file, as with fseek(), and return the
301 # current file position afterward. Also encapsulates ftell()'s
302 # functionality, just Set offset=0, whence=SEEK_CUR.
303 #
304 # @handle: filehandle returned by guest-file-open
305 #
306 # @offset: bytes to skip over in the file stream
307 #
308 # @whence: SEEK_SET, SEEK_CUR, or SEEK_END, as with fseek()
309 #
310 # Returns: @GuestFileSeek on success.
311 #
312 # Since: 0.15.0
313 ##
314 { 'command': 'guest-file-seek',
315 'data': { 'handle': 'int', 'offset': 'int', 'whence': 'int' },
316 'returns': 'GuestFileSeek' }
317
318 ##
319 # @guest-file-flush:
320 #
321 # Write file changes bufferred in userspace to disk/kernel buffers
322 #
323 # @handle: filehandle returned by guest-file-open
324 #
325 # Returns: Nothing on success.
326 #
327 # Since: 0.15.0
328 ##
329 { 'command': 'guest-file-flush',
330 'data': { 'handle': 'int' } }
331
332 ##
333 # @GuestFsFreezeStatus
334 #
335 # An enumeration of filesystem freeze states
336 #
337 # @thawed: filesystems thawed/unfrozen
338 #
339 # @frozen: all non-network guest filesystems frozen
340 #
341 # Since: 0.15.0
342 ##
343 { 'enum': 'GuestFsfreezeStatus',
344 'data': [ 'thawed', 'frozen' ] }
345
346 ##
347 # @guest-fsfreeze-status:
348 #
349 # Get guest fsfreeze state. error state indicates
350 #
351 # Returns: GuestFsfreezeStatus ("thawed", "frozen", etc., as defined below)
352 #
353 # Note: This may fail to properly report the current state as a result of
354 # some other guest processes having issued an fs freeze/thaw.
355 #
356 # Since: 0.15.0
357 ##
358 { 'command': 'guest-fsfreeze-status',
359 'returns': 'GuestFsfreezeStatus' }
360
361 ##
362 # @guest-fsfreeze-freeze:
363 #
364 # Sync and freeze all freezable, local guest filesystems
365 #
366 # Returns: Number of file systems currently frozen. On error, all filesystems
367 # will be thawed.
368 #
369 # Since: 0.15.0
370 ##
371 { 'command': 'guest-fsfreeze-freeze',
372 'returns': 'int' }
373
374 ##
375 # @guest-fsfreeze-thaw:
376 #
377 # Unfreeze all frozen guest filesystems
378 #
379 # Returns: Number of file systems thawed by this call
380 #
381 # Note: if return value does not match the previous call to
382 # guest-fsfreeze-freeze, this likely means some freezable
383 # filesystems were unfrozen before this call, and that the
384 # filesystem state may have changed before issuing this
385 # command.
386 #
387 # Since: 0.15.0
388 ##
389 { 'command': 'guest-fsfreeze-thaw',
390 'returns': 'int' }
391
392 ##
393 # @guest-fstrim:
394 #
395 # Discard (or "trim") blocks which are not in use by the filesystem.
396 #
397 # @minimum:
398 # Minimum contiguous free range to discard, in bytes. Free ranges
399 # smaller than this may be ignored (this is a hint and the guest
400 # may not respect it). By increasing this value, the fstrim
401 # operation will complete more quickly for filesystems with badly
402 # fragmented free space, although not all blocks will be discarded.
403 # The default value is zero, meaning "discard every free block".
404 #
405 # Returns: Nothing.
406 #
407 # Since: 1.2
408 ##
409 { 'command': 'guest-fstrim',
410 'data': { '*minimum': 'int' } }
411
412 ##
413 # @guest-suspend-disk
414 #
415 # Suspend guest to disk.
416 #
417 # This command tries to execute the scripts provided by the pm-utils package.
418 # If it's not available, the suspend operation will be performed by manually
419 # writing to a sysfs file.
420 #
421 # For the best results it's strongly recommended to have the pm-utils
422 # package installed in the guest.
423 #
424 # This command does NOT return a response on success. There is a high chance
425 # the command succeeded if the VM exits with a zero exit status or, when
426 # running with --no-shutdown, by issuing the query-status QMP command to
427 # to confirm the VM status is "shutdown". However, the VM could also exit
428 # (or set its status to "shutdown") due to other reasons.
429 #
430 # The following errors may be returned:
431 # If suspend to disk is not supported, Unsupported
432 #
433 # Notes: It's strongly recommended to issue the guest-sync command before
434 # sending commands when the guest resumes
435 #
436 # Since: 1.1
437 ##
438 { 'command': 'guest-suspend-disk', 'success-response': 'no' }
439
440 ##
441 # @guest-suspend-ram
442 #
443 # Suspend guest to ram.
444 #
445 # This command tries to execute the scripts provided by the pm-utils package.
446 # If it's not available, the suspend operation will be performed by manually
447 # writing to a sysfs file.
448 #
449 # For the best results it's strongly recommended to have the pm-utils
450 # package installed in the guest.
451 #
452 # IMPORTANT: guest-suspend-ram requires QEMU to support the 'system_wakeup'
453 # command. Thus, it's *required* to query QEMU for the presence of the
454 # 'system_wakeup' command before issuing guest-suspend-ram.
455 #
456 # This command does NOT return a response on success. There are two options
457 # to check for success:
458 # 1. Wait for the SUSPEND QMP event from QEMU
459 # 2. Issue the query-status QMP command to confirm the VM status is
460 # "suspended"
461 #
462 # The following errors may be returned:
463 # If suspend to ram is not supported, Unsupported
464 #
465 # Notes: It's strongly recommended to issue the guest-sync command before
466 # sending commands when the guest resumes
467 #
468 # Since: 1.1
469 ##
470 { 'command': 'guest-suspend-ram', 'success-response': 'no' }
471
472 ##
473 # @guest-suspend-hybrid
474 #
475 # Save guest state to disk and suspend to ram.
476 #
477 # This command requires the pm-utils package to be installed in the guest.
478 #
479 # IMPORTANT: guest-suspend-hybrid requires QEMU to support the 'system_wakeup'
480 # command. Thus, it's *required* to query QEMU for the presence of the
481 # 'system_wakeup' command before issuing guest-suspend-hybrid.
482 #
483 # This command does NOT return a response on success. There are two options
484 # to check for success:
485 # 1. Wait for the SUSPEND QMP event from QEMU
486 # 2. Issue the query-status QMP command to confirm the VM status is
487 # "suspended"
488 #
489 # The following errors may be returned:
490 # If hybrid suspend is not supported, Unsupported
491 #
492 # Notes: It's strongly recommended to issue the guest-sync command before
493 # sending commands when the guest resumes
494 #
495 # Since: 1.1
496 ##
497 { 'command': 'guest-suspend-hybrid', 'success-response': 'no' }
498
499 ##
500 # @GuestIpAddressType:
501 #
502 # An enumeration of supported IP address types
503 #
504 # @ipv4: IP version 4
505 #
506 # @ipv6: IP version 6
507 #
508 # Since: 1.1
509 ##
510 { 'enum': 'GuestIpAddressType',
511 'data': [ 'ipv4', 'ipv6' ] }
512
513 ##
514 # @GuestIpAddress:
515 #
516 # @ip-address: IP address
517 #
518 # @ip-address-type: Type of @ip-address (e.g. ipv4, ipv6)
519 #
520 # @prefix: Network prefix length of @ip-address
521 #
522 # Since: 1.1
523 ##
524 { 'type': 'GuestIpAddress',
525 'data': {'ip-address': 'str',
526 'ip-address-type': 'GuestIpAddressType',
527 'prefix': 'int'} }
528
529 ##
530 # @GuestNetworkInterface:
531 #
532 # @name: The name of interface for which info are being delivered
533 #
534 # @hardware-address: Hardware address of @name
535 #
536 # @ip-addresses: List of addresses assigned to @name
537 #
538 # Since: 1.1
539 ##
540 { 'type': 'GuestNetworkInterface',
541 'data': {'name': 'str',
542 '*hardware-address': 'str',
543 '*ip-addresses': ['GuestIpAddress'] } }
544
545 ##
546 # @guest-network-get-interfaces:
547 #
548 # Get list of guest IP addresses, MAC addresses
549 # and netmasks.
550 #
551 # Returns: List of GuestNetworkInfo on success.
552 #
553 # Since: 1.1
554 ##
555 { 'command': 'guest-network-get-interfaces',
556 'returns': ['GuestNetworkInterface'] }
557
558 ##
559 # @GuestLogicalProcessor:
560 #
561 # @logical-id: Arbitrary guest-specific unique identifier of the VCPU.
562 #
563 # @online: Whether the VCPU is enabled.
564 #
565 # @can-offline: Whether offlining the VCPU is possible. This member is always
566 # filled in by the guest agent when the structure is returned,
567 # and always ignored on input (hence it can be omitted then).
568 #
569 # Since: 1.5
570 ##
571 { 'type': 'GuestLogicalProcessor',
572 'data': {'logical-id': 'int',
573 'online': 'bool',
574 '*can-offline': 'bool'} }
575
576 ##
577 # @guest-get-vcpus:
578 #
579 # Retrieve the list of the guest's logical processors.
580 #
581 # This is a read-only operation.
582 #
583 # Returns: The list of all VCPUs the guest knows about. Each VCPU is put on the
584 # list exactly once, but their order is unspecified.
585 #
586 # Since: 1.5
587 ##
588 { 'command': 'guest-get-vcpus',
589 'returns': ['GuestLogicalProcessor'] }
590
591 ##
592 # @guest-set-vcpus:
593 #
594 # Attempt to reconfigure (currently: enable/disable) logical processors inside
595 # the guest.
596 #
597 # The input list is processed node by node in order. In each node @logical-id
598 # is used to look up the guest VCPU, for which @online specifies the requested
599 # state. The set of distinct @logical-id's is only required to be a subset of
600 # the guest-supported identifiers. There's no restriction on list length or on
601 # repeating the same @logical-id (with possibly different @online field).
602 # Preferably the input list should describe a modified subset of
603 # @guest-get-vcpus' return value.
604 #
605 # Returns: The length of the initial sublist that has been successfully
606 # processed. The guest agent maximizes this value. Possible cases:
607 #
608 # 0: if the @vcpus list was empty on input. Guest state
609 # has not been changed. Otherwise,
610 #
611 # Error: processing the first node of @vcpus failed for the
612 # reason returned. Guest state has not been changed.
613 # Otherwise,
614 #
615 # < length(@vcpus): more than zero initial nodes have been processed,
616 # but not the entire @vcpus list. Guest state has
617 # changed accordingly. To retrieve the error
618 # (assuming it persists), repeat the call with the
619 # successfully processed initial sublist removed.
620 # Otherwise,
621 #
622 # length(@vcpus): call successful.
623 #
624 # Since: 1.5
625 ##
626 { 'command': 'guest-set-vcpus',
627 'data': {'vcpus': ['GuestLogicalProcessor'] },
628 'returns': 'int' }