]> git.proxmox.com Git - qemu.git/blob - qga/qapi-schema.json
Merge remote-tracking branch 'qemu-kvm/uq/master' into staging
[qemu.git] / qga / qapi-schema.json
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' }