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' } } 390