]> git.proxmox.com Git - mirror_qemu.git/blob - qapi/event.json
qmp-events: move 'SUSPEND_DISK' doc to schema
[mirror_qemu.git] / qapi / event.json
1 # -*- Mode: Python -*-
2
3 ##
4 # = Other events
5 ##
6
7 ##
8 # @SHUTDOWN:
9 #
10 # Emitted when the virtual machine has shut down, indicating that qemu is
11 # about to exit.
12 #
13 # Note: If the command-line option "-no-shutdown" has been specified, qemu will
14 # not exit, and a STOP event will eventually follow the SHUTDOWN event
15 #
16 # Since: 0.12.0
17 #
18 # Example:
19 #
20 # <- { "event": "SHUTDOWN",
21 # "timestamp": { "seconds": 1267040730, "microseconds": 682951 } }
22 #
23 ##
24 { 'event': 'SHUTDOWN' }
25
26 ##
27 # @POWERDOWN:
28 #
29 # Emitted when the virtual machine is powered down through the power control
30 # system, such as via ACPI.
31 #
32 # Since: 0.12.0
33 #
34 # Example:
35 #
36 # <- { "event": "POWERDOWN",
37 # "timestamp": { "seconds": 1267040730, "microseconds": 682951 } }
38 #
39 ##
40 { 'event': 'POWERDOWN' }
41
42 ##
43 # @RESET:
44 #
45 # Emitted when the virtual machine is reset
46 #
47 # Since: 0.12.0
48 #
49 # Example:
50 #
51 # <- { "event": "RESET",
52 # "timestamp": { "seconds": 1267041653, "microseconds": 9518 } }
53 #
54 ##
55 { 'event': 'RESET' }
56
57 ##
58 # @STOP:
59 #
60 # Emitted when the virtual machine is stopped
61 #
62 # Since: 0.12.0
63 #
64 # Example:
65 #
66 # <- { "event": "STOP",
67 # "timestamp": { "seconds": 1267041730, "microseconds": 281295 } }
68 #
69 ##
70 { 'event': 'STOP' }
71
72 ##
73 # @RESUME:
74 #
75 # Emitted when the virtual machine resumes execution
76 #
77 # Since: 0.12.0
78 #
79 # Example:
80 #
81 # <- { "event": "RESUME",
82 # "timestamp": { "seconds": 1271770767, "microseconds": 582542 } }
83 #
84 ##
85 { 'event': 'RESUME' }
86
87 ##
88 # @SUSPEND:
89 #
90 # Emitted when guest enters a hardware suspension state, for example, S3 state,
91 # which is sometimes called standby state
92 #
93 # Since: 1.1
94 #
95 # Example:
96 #
97 # <- { "event": "SUSPEND",
98 # "timestamp": { "seconds": 1344456160, "microseconds": 309119 } }
99 #
100 ##
101 { 'event': 'SUSPEND' }
102
103 ##
104 # @SUSPEND_DISK:
105 #
106 # Emitted when guest enters a hardware suspension state with data saved on
107 # disk, for example, S4 state, which is sometimes called hibernate state
108 #
109 # Note: QEMU shuts down (similar to event @SHUTDOWN) when entering this state
110 #
111 # Since: 1.2
112 #
113 # Example:
114 #
115 # <- { "event": "SUSPEND_DISK",
116 # "timestamp": { "seconds": 1344456160, "microseconds": 309119 } }
117 #
118 ##
119 { 'event': 'SUSPEND_DISK' }
120
121 ##
122 # @WAKEUP:
123 #
124 # Emitted when the guest has woken up from suspend state and is running
125 #
126 # Since: 1.1
127 ##
128 { 'event': 'WAKEUP' }
129
130 ##
131 # @RTC_CHANGE:
132 #
133 # Emitted when the guest changes the RTC time.
134 #
135 # @offset: offset between base RTC clock (as specified by -rtc base), and
136 # new RTC clock value
137 #
138 # Since: 0.13.0
139 ##
140 { 'event': 'RTC_CHANGE',
141 'data': { 'offset': 'int' } }
142
143 ##
144 # @WATCHDOG:
145 #
146 # Emitted when the watchdog device's timer is expired
147 #
148 # @action: action that has been taken
149 #
150 # Note: If action is "reset", "shutdown", or "pause" the WATCHDOG event is
151 # followed respectively by the RESET, SHUTDOWN, or STOP events
152 #
153 # Since: 0.13.0
154 ##
155 { 'event': 'WATCHDOG',
156 'data': { 'action': 'WatchdogExpirationAction' } }
157
158 ##
159 # @DEVICE_DELETED:
160 #
161 # Emitted whenever the device removal completion is acknowledged by the guest.
162 # At this point, it's safe to reuse the specified device ID. Device removal can
163 # be initiated by the guest or by HMP/QMP commands.
164 #
165 # @device: #optional, device name
166 #
167 # @path: device path
168 #
169 # Since: 1.5
170 ##
171 { 'event': 'DEVICE_DELETED',
172 'data': { '*device': 'str', 'path': 'str' } }
173
174 ##
175 # @NIC_RX_FILTER_CHANGED:
176 #
177 # Emitted once until the 'query-rx-filter' command is executed, the first event
178 # will always be emitted
179 #
180 # @name: #optional, net client name
181 #
182 # @path: device path
183 #
184 # Since: 1.6
185 ##
186 { 'event': 'NIC_RX_FILTER_CHANGED',
187 'data': { '*name': 'str', 'path': 'str' } }
188
189 ##
190 # @VNC_CONNECTED:
191 #
192 # Emitted when a VNC client establishes a connection
193 #
194 # @server: server information
195 #
196 # @client: client information
197 #
198 # Note: This event is emitted before any authentication takes place, thus
199 # the authentication ID is not provided
200 #
201 # Since: 0.13.0
202 ##
203 { 'event': 'VNC_CONNECTED',
204 'data': { 'server': 'VncServerInfo',
205 'client': 'VncBasicInfo' } }
206
207 ##
208 # @VNC_INITIALIZED:
209 #
210 # Emitted after authentication takes place (if any) and the VNC session is
211 # made active
212 #
213 # @server: server information
214 #
215 # @client: client information
216 #
217 # Since: 0.13.0
218 ##
219 { 'event': 'VNC_INITIALIZED',
220 'data': { 'server': 'VncServerInfo',
221 'client': 'VncClientInfo' } }
222
223 ##
224 # @VNC_DISCONNECTED:
225 #
226 # Emitted when the connection is closed
227 #
228 # @server: server information
229 #
230 # @client: client information
231 #
232 # Since: 0.13.0
233 ##
234 { 'event': 'VNC_DISCONNECTED',
235 'data': { 'server': 'VncServerInfo',
236 'client': 'VncClientInfo' } }
237
238 ##
239 # @SPICE_CONNECTED:
240 #
241 # Emitted when a SPICE client establishes a connection
242 #
243 # @server: server information
244 #
245 # @client: client information
246 #
247 # Since: 0.14.0
248 ##
249 { 'event': 'SPICE_CONNECTED',
250 'data': { 'server': 'SpiceBasicInfo',
251 'client': 'SpiceBasicInfo' } }
252
253 ##
254 # @SPICE_INITIALIZED:
255 #
256 # Emitted after initial handshake and authentication takes place (if any)
257 # and the SPICE channel is up and running
258 #
259 # @server: server information
260 #
261 # @client: client information
262 #
263 # Since: 0.14.0
264 ##
265 { 'event': 'SPICE_INITIALIZED',
266 'data': { 'server': 'SpiceServerInfo',
267 'client': 'SpiceChannel' } }
268
269 ##
270 # @SPICE_DISCONNECTED:
271 #
272 # Emitted when the SPICE connection is closed
273 #
274 # @server: server information
275 #
276 # @client: client information
277 #
278 # Since: 0.14.0
279 ##
280 { 'event': 'SPICE_DISCONNECTED',
281 'data': { 'server': 'SpiceBasicInfo',
282 'client': 'SpiceBasicInfo' } }
283
284 ##
285 # @SPICE_MIGRATE_COMPLETED:
286 #
287 # Emitted when SPICE migration has completed
288 #
289 # Since: 1.3
290 ##
291 { 'event': 'SPICE_MIGRATE_COMPLETED' }
292
293 ##
294 # @MIGRATION:
295 #
296 # Emitted when a migration event happens
297 #
298 # @status: @MigrationStatus describing the current migration status.
299 #
300 # Since: 2.4
301 ##
302 { 'event': 'MIGRATION',
303 'data': {'status': 'MigrationStatus'}}
304
305 ##
306 # @MIGRATION_PASS:
307 #
308 # Emitted from the source side of a migration at the start of each pass
309 # (when it syncs the dirty bitmap)
310 #
311 # @pass: An incrementing count (starting at 1 on the first pass)
312 #
313 # Since: 2.6
314 ##
315 { 'event': 'MIGRATION_PASS',
316 'data': { 'pass': 'int' } }
317
318 ##
319 # @ACPI_DEVICE_OST:
320 #
321 # Emitted when guest executes ACPI _OST method.
322 #
323 # @info: ACPIOSTInfo type as described in qapi-schema.json
324 #
325 # Since: 2.1
326 ##
327 { 'event': 'ACPI_DEVICE_OST',
328 'data': { 'info': 'ACPIOSTInfo' } }
329
330 ##
331 # @BALLOON_CHANGE:
332 #
333 # Emitted when the guest changes the actual BALLOON level. This value is
334 # equivalent to the @actual field return by the 'query-balloon' command
335 #
336 # @actual: actual level of the guest memory balloon in bytes
337 #
338 # Since: 1.2
339 ##
340 { 'event': 'BALLOON_CHANGE',
341 'data': { 'actual': 'int' } }
342
343 ##
344 # @GUEST_PANICKED:
345 #
346 # Emitted when guest OS panic is detected
347 #
348 # @action: action that has been taken, currently always "pause"
349 #
350 # Since: 1.5
351 ##
352 { 'event': 'GUEST_PANICKED',
353 'data': { 'action': 'GuestPanicAction' } }
354
355 ##
356 # @QUORUM_FAILURE:
357 #
358 # Emitted by the Quorum block driver if it fails to establish a quorum
359 #
360 # @reference: device name if defined else node name
361 #
362 # @sector-num: number of the first sector of the failed read operation
363 #
364 # @sectors-count: failed read operation sector count
365 #
366 # Since: 2.0
367 ##
368 { 'event': 'QUORUM_FAILURE',
369 'data': { 'reference': 'str', 'sector-num': 'int', 'sectors-count': 'int' } }
370
371 ##
372 # @QUORUM_REPORT_BAD:
373 #
374 # Emitted to report a corruption of a Quorum file
375 #
376 # @type: quorum operation type (Since 2.6)
377 #
378 # @error: #optional, error message. Only present on failure. This field
379 # contains a human-readable error message. There are no semantics other
380 # than that the block layer reported an error and clients should not
381 # try to interpret the error string.
382 #
383 # @node-name: the graph node name of the block driver state
384 #
385 # @sector-num: number of the first sector of the failed read operation
386 #
387 # @sectors-count: failed read operation sector count
388 #
389 # Since: 2.0
390 ##
391 { 'event': 'QUORUM_REPORT_BAD',
392 'data': { 'type': 'QuorumOpType', '*error': 'str', 'node-name': 'str',
393 'sector-num': 'int', 'sectors-count': 'int' } }
394
395 ##
396 # @VSERPORT_CHANGE:
397 #
398 # Emitted when the guest opens or closes a virtio-serial port.
399 #
400 # @id: device identifier of the virtio-serial port
401 #
402 # @open: true if the guest has opened the virtio-serial port
403 #
404 # Since: 2.1
405 ##
406 { 'event': 'VSERPORT_CHANGE',
407 'data': { 'id': 'str', 'open': 'bool' } }
408
409 ##
410 # @MEM_UNPLUG_ERROR:
411 #
412 # Emitted when memory hot unplug error occurs.
413 #
414 # @device: device name
415 #
416 # @msg: Informative message
417 #
418 # Since: 2.4
419 ##
420 { 'event': 'MEM_UNPLUG_ERROR',
421 'data': { 'device': 'str', 'msg': 'str' } }
422
423 ##
424 # @DUMP_COMPLETED:
425 #
426 # Emitted when background dump has completed
427 #
428 # @result: DumpQueryResult type described in qapi-schema.json.
429 #
430 # @error: #optional human-readable error string that provides
431 # hint on why dump failed. Only presents on failure. The
432 # user should not try to interpret the error string.
433 #
434 # Since: 2.6
435 ##
436 { 'event': 'DUMP_COMPLETED' ,
437 'data': { 'result': 'DumpQueryResult', '*error': 'str' } }