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