xref: /qemu/qapi/migration.json (revision 19f9c044)
1# -*- Mode: Python -*-
2# vim: filetype=python
3#
4
5##
6# = Migration
7##
8
9{ 'include': 'common.json' }
10{ 'include': 'sockets.json' }
11
12##
13# @MigrationStats:
14#
15# Detailed migration status.
16#
17# @transferred: amount of bytes already transferred to the target VM
18#
19# @remaining: amount of bytes remaining to be transferred to the
20#     target VM
21#
22# @total: total amount of bytes involved in the migration process
23#
24# @duplicate: number of duplicate (zero) pages (since 1.2)
25#
26# @skipped: number of skipped zero pages. Always zero, only provided for
27#     compatibility (since 1.5)
28#
29# @normal: number of normal pages (since 1.2)
30#
31# @normal-bytes: number of normal bytes sent (since 1.2)
32#
33# @dirty-pages-rate: number of pages dirtied by second by the guest
34#     (since 1.3)
35#
36# @mbps: throughput in megabits/sec.  (since 1.6)
37#
38# @dirty-sync-count: number of times that dirty ram was synchronized
39#     (since 2.1)
40#
41# @postcopy-requests: The number of page requests received from the
42#     destination (since 2.7)
43#
44# @page-size: The number of bytes per page for the various page-based
45#     statistics (since 2.10)
46#
47# @multifd-bytes: The number of bytes sent through multifd (since 3.0)
48#
49# @pages-per-second: the number of memory pages transferred per second
50#     (Since 4.0)
51#
52# @precopy-bytes: The number of bytes sent in the pre-copy phase
53#     (since 7.0).
54#
55# @downtime-bytes: The number of bytes sent while the guest is paused
56#     (since 7.0).
57#
58# @postcopy-bytes: The number of bytes sent during the post-copy phase
59#     (since 7.0).
60#
61# @dirty-sync-missed-zero-copy: Number of times dirty RAM
62#     synchronization could not avoid copying dirty pages.  This is
63#     between 0 and @dirty-sync-count * @multifd-channels.  (since
64#     7.1)
65#
66# Features:
67#
68# @deprecated: Member @skipped is always zero since 1.5.3
69#
70# Since: 0.14
71#
72##
73{ 'struct': 'MigrationStats',
74  'data': {'transferred': 'int', 'remaining': 'int', 'total': 'int' ,
75           'duplicate': 'int',
76           'skipped': { 'type': 'int', 'features': [ 'deprecated' ] },
77           'normal': 'int',
78           'normal-bytes': 'int', 'dirty-pages-rate': 'int',
79           'mbps': 'number', 'dirty-sync-count': 'int',
80           'postcopy-requests': 'int', 'page-size': 'int',
81           'multifd-bytes': 'uint64', 'pages-per-second': 'uint64',
82           'precopy-bytes': 'uint64', 'downtime-bytes': 'uint64',
83           'postcopy-bytes': 'uint64',
84           'dirty-sync-missed-zero-copy': 'uint64' } }
85
86##
87# @XBZRLECacheStats:
88#
89# Detailed XBZRLE migration cache statistics
90#
91# @cache-size: XBZRLE cache size
92#
93# @bytes: amount of bytes already transferred to the target VM
94#
95# @pages: amount of pages transferred to the target VM
96#
97# @cache-miss: number of cache miss
98#
99# @cache-miss-rate: rate of cache miss (since 2.1)
100#
101# @encoding-rate: rate of encoded bytes (since 5.1)
102#
103# @overflow: number of overflows
104#
105# Since: 1.2
106##
107{ 'struct': 'XBZRLECacheStats',
108  'data': {'cache-size': 'size', 'bytes': 'int', 'pages': 'int',
109           'cache-miss': 'int', 'cache-miss-rate': 'number',
110           'encoding-rate': 'number', 'overflow': 'int' } }
111
112##
113# @CompressionStats:
114#
115# Detailed migration compression statistics
116#
117# @pages: amount of pages compressed and transferred to the target VM
118#
119# @busy: count of times that no free thread was available to compress
120#     data
121#
122# @busy-rate: rate of thread busy
123#
124# @compressed-size: amount of bytes after compression
125#
126# @compression-rate: rate of compressed size
127#
128# Since: 3.1
129##
130{ 'struct': 'CompressionStats',
131  'data': {'pages': 'int', 'busy': 'int', 'busy-rate': 'number',
132           'compressed-size': 'int', 'compression-rate': 'number' } }
133
134##
135# @MigrationStatus:
136#
137# An enumeration of migration status.
138#
139# @none: no migration has ever happened.
140#
141# @setup: migration process has been initiated.
142#
143# @cancelling: in the process of cancelling migration.
144#
145# @cancelled: cancelling migration is finished.
146#
147# @active: in the process of doing migration.
148#
149# @postcopy-active: like active, but now in postcopy mode.  (since
150#     2.5)
151#
152# @postcopy-paused: during postcopy but paused.  (since 3.0)
153#
154# @postcopy-recover: trying to recover from a paused postcopy.  (since
155#     3.0)
156#
157# @completed: migration is finished.
158#
159# @failed: some error occurred during migration process.
160#
161# @colo: VM is in the process of fault tolerance, VM can not get into
162#     this state unless colo capability is enabled for migration.
163#     (since 2.8)
164#
165# @pre-switchover: Paused before device serialisation.  (since 2.11)
166#
167# @device: During device serialisation when pause-before-switchover is
168#     enabled (since 2.11)
169#
170# @wait-unplug: wait for device unplug request by guest OS to be
171#     completed.  (since 4.2)
172#
173# Since: 2.3
174##
175{ 'enum': 'MigrationStatus',
176  'data': [ 'none', 'setup', 'cancelling', 'cancelled',
177            'active', 'postcopy-active', 'postcopy-paused',
178            'postcopy-recover', 'completed', 'failed', 'colo',
179            'pre-switchover', 'device', 'wait-unplug' ] }
180##
181# @VfioStats:
182#
183# Detailed VFIO devices migration statistics
184#
185# @transferred: amount of bytes transferred to the target VM by VFIO
186#     devices
187#
188# Since: 5.2
189##
190{ 'struct': 'VfioStats',
191  'data': {'transferred': 'int' } }
192
193##
194# @MigrationInfo:
195#
196# Information about current migration process.
197#
198# @status: @MigrationStatus describing the current migration status.
199#     If this field is not returned, no migration process has been
200#     initiated
201#
202# @ram: @MigrationStats containing detailed migration status, only
203#     returned if status is 'active' or 'completed'(since 1.2)
204#
205# @disk: @MigrationStats containing detailed disk migration status,
206#     only returned if status is 'active' and it is a block migration
207#
208# @xbzrle-cache: @XBZRLECacheStats containing detailed XBZRLE
209#     migration statistics, only returned if XBZRLE feature is on and
210#     status is 'active' or 'completed' (since 1.2)
211#
212# @total-time: total amount of milliseconds since migration started.
213#     If migration has ended, it returns the total migration time.
214#     (since 1.2)
215#
216# @downtime: only present when migration finishes correctly total
217#     downtime in milliseconds for the guest.  (since 1.3)
218#
219# @expected-downtime: only present while migration is active expected
220#     downtime in milliseconds for the guest in last walk of the dirty
221#     bitmap.  (since 1.3)
222#
223# @setup-time: amount of setup time in milliseconds *before* the
224#     iterations begin but *after* the QMP command is issued.  This is
225#     designed to provide an accounting of any activities (such as
226#     RDMA pinning) which may be expensive, but do not actually occur
227#     during the iterative migration rounds themselves.  (since 1.6)
228#
229# @cpu-throttle-percentage: percentage of time guest cpus are being
230#     throttled during auto-converge.  This is only present when
231#     auto-converge has started throttling guest cpus.  (Since 2.7)
232#
233# @error-desc: the human readable error description string. Clients
234#     should not attempt to parse the error strings.  (Since 2.7)
235#
236# @postcopy-blocktime: total time when all vCPU were blocked during
237#     postcopy live migration.  This is only present when the
238#     postcopy-blocktime migration capability is enabled.  (Since 3.0)
239#
240# @postcopy-vcpu-blocktime: list of the postcopy blocktime per vCPU.
241#     This is only present when the postcopy-blocktime migration
242#     capability is enabled.  (Since 3.0)
243#
244# @compression: migration compression statistics, only returned if
245#     compression feature is on and status is 'active' or 'completed'
246#     (Since 3.1)
247#
248# @socket-address: Only used for tcp, to know what the real port is
249#     (Since 4.0)
250#
251# @vfio: @VfioStats containing detailed VFIO devices migration
252#     statistics, only returned if VFIO device is present, migration
253#     is supported by all VFIO devices and status is 'active' or
254#     'completed' (since 5.2)
255#
256# @blocked-reasons: A list of reasons an outgoing migration is
257#     blocked.  Present and non-empty when migration is blocked.
258#     (since 6.0)
259#
260# @dirty-limit-throttle-time-per-round: Maximum throttle time
261#     (in microseconds) of virtual CPUs each dirty ring full round,
262#     which shows how MigrationCapability dirty-limit affects the
263#     guest during live migration.  (Since 8.1)
264#
265# @dirty-limit-ring-full-time: Estimated average dirty ring full time
266#     (in microseconds) for each dirty ring full round.  The value
267#     equals the dirty ring memory size divided by the average dirty
268#     page rate of the virtual CPU, which can be used to observe the
269#     average memory load of the virtual CPU indirectly.  Note that
270#     zero means guest doesn't dirty memory.  (Since 8.1)
271#
272# Features:
273#
274# @deprecated: Member @disk is deprecated because block migration is.
275#     Member @compression is deprecated because it is unreliable and
276#     untested.  It is recommended to use multifd migration, which
277#     offers an alternative compression implementation that is
278#     reliable and tested.
279#
280# Since: 0.14
281##
282{ 'struct': 'MigrationInfo',
283  'data': {'*status': 'MigrationStatus', '*ram': 'MigrationStats',
284           '*disk': { 'type': 'MigrationStats', 'features': [ 'deprecated' ] },
285           '*vfio': 'VfioStats',
286           '*xbzrle-cache': 'XBZRLECacheStats',
287           '*total-time': 'int',
288           '*expected-downtime': 'int',
289           '*downtime': 'int',
290           '*setup-time': 'int',
291           '*cpu-throttle-percentage': 'int',
292           '*error-desc': 'str',
293           '*blocked-reasons': ['str'],
294           '*postcopy-blocktime': 'uint32',
295           '*postcopy-vcpu-blocktime': ['uint32'],
296           '*compression': { 'type': 'CompressionStats', 'features': [ 'deprecated' ] },
297           '*socket-address': ['SocketAddress'],
298           '*dirty-limit-throttle-time-per-round': 'uint64',
299           '*dirty-limit-ring-full-time': 'uint64'} }
300
301##
302# @query-migrate:
303#
304# Returns information about current migration process.  If migration
305# is active there will be another json-object with RAM migration
306# status and if block migration is active another one with block
307# migration status.
308#
309# Returns: @MigrationInfo
310#
311# Since: 0.14
312#
313# Examples:
314#
315#     1. Before the first migration
316#
317#     -> { "execute": "query-migrate" }
318#     <- { "return": {} }
319#
320#     2. Migration is done and has succeeded
321#
322#     -> { "execute": "query-migrate" }
323#     <- { "return": {
324#             "status": "completed",
325#             "total-time":12345,
326#             "setup-time":12345,
327#             "downtime":12345,
328#             "ram":{
329#               "transferred":123,
330#               "remaining":123,
331#               "total":246,
332#               "duplicate":123,
333#               "normal":123,
334#               "normal-bytes":123456,
335#               "dirty-sync-count":15
336#             }
337#          }
338#        }
339#
340#     3. Migration is done and has failed
341#
342#     -> { "execute": "query-migrate" }
343#     <- { "return": { "status": "failed" } }
344#
345#     4. Migration is being performed and is not a block migration:
346#
347#     -> { "execute": "query-migrate" }
348#     <- {
349#           "return":{
350#              "status":"active",
351#              "total-time":12345,
352#              "setup-time":12345,
353#              "expected-downtime":12345,
354#              "ram":{
355#                 "transferred":123,
356#                 "remaining":123,
357#                 "total":246,
358#                 "duplicate":123,
359#                 "normal":123,
360#                 "normal-bytes":123456,
361#                 "dirty-sync-count":15
362#              }
363#           }
364#        }
365#
366#     5. Migration is being performed and is a block migration:
367#
368#     -> { "execute": "query-migrate" }
369#     <- {
370#           "return":{
371#              "status":"active",
372#              "total-time":12345,
373#              "setup-time":12345,
374#              "expected-downtime":12345,
375#              "ram":{
376#                 "total":1057024,
377#                 "remaining":1053304,
378#                 "transferred":3720,
379#                 "duplicate":123,
380#                 "normal":123,
381#                 "normal-bytes":123456,
382#                 "dirty-sync-count":15
383#              },
384#              "disk":{
385#                 "total":20971520,
386#                 "remaining":20880384,
387#                 "transferred":91136
388#              }
389#           }
390#        }
391#
392#     6. Migration is being performed and XBZRLE is active:
393#
394#     -> { "execute": "query-migrate" }
395#     <- {
396#           "return":{
397#              "status":"active",
398#              "total-time":12345,
399#              "setup-time":12345,
400#              "expected-downtime":12345,
401#              "ram":{
402#                 "total":1057024,
403#                 "remaining":1053304,
404#                 "transferred":3720,
405#                 "duplicate":10,
406#                 "normal":3333,
407#                 "normal-bytes":3412992,
408#                 "dirty-sync-count":15
409#              },
410#              "xbzrle-cache":{
411#                 "cache-size":67108864,
412#                 "bytes":20971520,
413#                 "pages":2444343,
414#                 "cache-miss":2244,
415#                 "cache-miss-rate":0.123,
416#                 "encoding-rate":80.1,
417#                 "overflow":34434
418#              }
419#           }
420#        }
421##
422{ 'command': 'query-migrate', 'returns': 'MigrationInfo' }
423
424##
425# @MigrationCapability:
426#
427# Migration capabilities enumeration
428#
429# @xbzrle: Migration supports xbzrle (Xor Based Zero Run Length
430#     Encoding). This feature allows us to minimize migration traffic
431#     for certain work loads, by sending compressed difference of the
432#     pages
433#
434# @rdma-pin-all: Controls whether or not the entire VM memory
435#     footprint is mlock()'d on demand or all at once.  Refer to
436#     docs/rdma.txt for usage.  Disabled by default.  (since 2.0)
437#
438# @zero-blocks: During storage migration encode blocks of zeroes
439#     efficiently.  This essentially saves 1MB of zeroes per block on
440#     the wire.  Enabling requires source and target VM to support
441#     this feature.  To enable it is sufficient to enable the
442#     capability on the source VM. The feature is disabled by default.
443#     (since 1.6)
444#
445# @compress: Use multiple compression threads to accelerate live
446#     migration.  This feature can help to reduce the migration
447#     traffic, by sending compressed pages.  Please note that if
448#     compress and xbzrle are both on, compress only takes effect in
449#     the ram bulk stage, after that, it will be disabled and only
450#     xbzrle takes effect, this can help to minimize migration
451#     traffic.  The feature is disabled by default.  (since 2.4)
452#
453# @events: generate events for each migration state change (since 2.4)
454#
455# @auto-converge: If enabled, QEMU will automatically throttle down
456#     the guest to speed up convergence of RAM migration.  (since 1.6)
457#
458# @postcopy-ram: Start executing on the migration target before all of
459#     RAM has been migrated, pulling the remaining pages along as
460#     needed.  The capacity must have the same setting on both source
461#     and target or migration will not even start.  NOTE: If the
462#     migration fails during postcopy the VM will fail.  (since 2.6)
463#
464# @x-colo: If enabled, migration will never end, and the state of the
465#     VM on the primary side will be migrated continuously to the VM
466#     on secondary side, this process is called COarse-Grain LOck
467#     Stepping (COLO) for Non-stop Service.  (since 2.8)
468#
469# @release-ram: if enabled, qemu will free the migrated ram pages on
470#     the source during postcopy-ram migration.  (since 2.9)
471#
472# @block: If enabled, QEMU will also migrate the contents of all block
473#     devices.  Default is disabled.  A possible alternative uses
474#     mirror jobs to a builtin NBD server on the destination, which
475#     offers more flexibility.  (Since 2.10)
476#
477# @return-path: If enabled, migration will use the return path even
478#     for precopy.  (since 2.10)
479#
480# @pause-before-switchover: Pause outgoing migration before
481#     serialising device state and before disabling block IO (since
482#     2.11)
483#
484# @multifd: Use more than one fd for migration (since 4.0)
485#
486# @dirty-bitmaps: If enabled, QEMU will migrate named dirty bitmaps.
487#     (since 2.12)
488#
489# @postcopy-blocktime: Calculate downtime for postcopy live migration
490#     (since 3.0)
491#
492# @late-block-activate: If enabled, the destination will not activate
493#     block devices (and thus take locks) immediately at the end of
494#     migration.  (since 3.0)
495#
496# @x-ignore-shared: If enabled, QEMU will not migrate shared memory
497#     that is accessible on the destination machine.  (since 4.0)
498#
499# @validate-uuid: Send the UUID of the source to allow the destination
500#     to ensure it is the same.  (since 4.2)
501#
502# @background-snapshot: If enabled, the migration stream will be a
503#     snapshot of the VM exactly at the point when the migration
504#     procedure starts.  The VM RAM is saved with running VM. (since
505#     6.0)
506#
507# @zero-copy-send: Controls behavior on sending memory pages on
508#     migration.  When true, enables a zero-copy mechanism for sending
509#     memory pages, if host supports it.  Requires that QEMU be
510#     permitted to use locked memory for guest RAM pages.  (since 7.1)
511#
512# @postcopy-preempt: If enabled, the migration process will allow
513#     postcopy requests to preempt precopy stream, so postcopy
514#     requests will be handled faster.  This is a performance feature
515#     and should not affect the correctness of postcopy migration.
516#     (since 7.1)
517#
518# @switchover-ack: If enabled, migration will not stop the source VM
519#     and complete the migration until an ACK is received from the
520#     destination that it's OK to do so.  Exactly when this ACK is
521#     sent depends on the migrated devices that use this feature.  For
522#     example, a device can use it to make sure some of its data is
523#     sent and loaded in the destination before doing switchover.
524#     This can reduce downtime if devices that support this capability
525#     are present.  'return-path' capability must be enabled to use
526#     it.  (since 8.1)
527#
528# @dirty-limit: If enabled, migration will throttle vCPUs as needed to
529#     keep their dirty page rate within @vcpu-dirty-limit.  This can
530#     improve responsiveness of large guests during live migration,
531#     and can result in more stable read performance.  Requires KVM
532#     with accelerator property "dirty-ring-size" set.  (Since 8.1)
533#
534# Features:
535#
536# @deprecated: Member @block is deprecated.  Use blockdev-mirror with
537#     NBD instead.  Member @compress is deprecated because it is
538#     unreliable and untested.  It is recommended to use multifd
539#     migration, which offers an alternative compression
540#     implementation that is reliable and tested.
541#
542# @unstable: Members @x-colo and @x-ignore-shared are experimental.
543#
544# Since: 1.2
545##
546{ 'enum': 'MigrationCapability',
547  'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks',
548           { 'name': 'compress', 'features': [ 'deprecated' ] },
549           'events', 'postcopy-ram',
550           { 'name': 'x-colo', 'features': [ 'unstable' ] },
551           'release-ram',
552           { 'name': 'block', 'features': [ 'deprecated' ] },
553           'return-path', 'pause-before-switchover', 'multifd',
554           'dirty-bitmaps', 'postcopy-blocktime', 'late-block-activate',
555           { 'name': 'x-ignore-shared', 'features': [ 'unstable' ] },
556           'validate-uuid', 'background-snapshot',
557           'zero-copy-send', 'postcopy-preempt', 'switchover-ack',
558           'dirty-limit'] }
559
560##
561# @MigrationCapabilityStatus:
562#
563# Migration capability information
564#
565# @capability: capability enum
566#
567# @state: capability state bool
568#
569# Since: 1.2
570##
571{ 'struct': 'MigrationCapabilityStatus',
572  'data': { 'capability': 'MigrationCapability', 'state': 'bool' } }
573
574##
575# @migrate-set-capabilities:
576#
577# Enable/Disable the following migration capabilities (like xbzrle)
578#
579# @capabilities: json array of capability modifications to make
580#
581# Since: 1.2
582#
583# Example:
584#
585#     -> { "execute": "migrate-set-capabilities" , "arguments":
586#          { "capabilities": [ { "capability": "xbzrle", "state": true } ] } }
587#     <- { "return": {} }
588##
589{ 'command': 'migrate-set-capabilities',
590  'data': { 'capabilities': ['MigrationCapabilityStatus'] } }
591
592##
593# @query-migrate-capabilities:
594#
595# Returns information about the current migration capabilities status
596#
597# Returns: @MigrationCapabilityStatus
598#
599# Since: 1.2
600#
601# Example:
602#
603#     -> { "execute": "query-migrate-capabilities" }
604#     <- { "return": [
605#           {"state": false, "capability": "xbzrle"},
606#           {"state": false, "capability": "rdma-pin-all"},
607#           {"state": false, "capability": "auto-converge"},
608#           {"state": false, "capability": "zero-blocks"},
609#           {"state": false, "capability": "compress"},
610#           {"state": true, "capability": "events"},
611#           {"state": false, "capability": "postcopy-ram"},
612#           {"state": false, "capability": "x-colo"}
613#        ]}
614##
615{ 'command': 'query-migrate-capabilities', 'returns':   ['MigrationCapabilityStatus']}
616
617##
618# @MultiFDCompression:
619#
620# An enumeration of multifd compression methods.
621#
622# @none: no compression.
623#
624# @zlib: use zlib compression method.
625#
626# @zstd: use zstd compression method.
627#
628# Since: 5.0
629##
630{ 'enum': 'MultiFDCompression',
631  'data': [ 'none', 'zlib',
632            { 'name': 'zstd', 'if': 'CONFIG_ZSTD' } ] }
633
634##
635# @MigMode:
636#
637# @normal: the original form of migration. (since 8.2)
638#
639# @cpr-reboot: The migrate command stops the VM and saves state to the URI.
640#     After quitting qemu, the user resumes by running qemu -incoming.
641#
642#     This mode allows the user to quit qemu, and restart an updated version
643#     of qemu.  The user may even update and reboot the OS before restarting,
644#     as long as the URI persists across a reboot.
645#
646#     Unlike normal mode, the use of certain local storage options does not
647#     block the migration, but the user must not modify guest block devices
648#     between the quit and restart.
649#
650#     This mode supports vfio devices provided the user first puts the guest
651#     in the suspended runstate, such as by issuing guest-suspend-ram to the
652#     qemu guest agent.
653#
654#     Best performance is achieved when the memory backend is shared and the
655#     @x-ignore-shared migration capability is set, but this is not required.
656#     Further, if the user reboots before restarting such a configuration, the
657#     shared backend must be be non-volatile across reboot, such as by backing
658#     it with a dax device.
659#
660#     cpr-reboot may not be used with postcopy, colo, or background-snapshot.
661#
662#     (since 8.2)
663##
664{ 'enum': 'MigMode',
665  'data': [ 'normal', 'cpr-reboot' ] }
666
667##
668# @BitmapMigrationBitmapAliasTransform:
669#
670# @persistent: If present, the bitmap will be made persistent or
671#     transient depending on this parameter.
672#
673# Since: 6.0
674##
675{ 'struct': 'BitmapMigrationBitmapAliasTransform',
676  'data': {
677      '*persistent': 'bool'
678  } }
679
680##
681# @BitmapMigrationBitmapAlias:
682#
683# @name: The name of the bitmap.
684#
685# @alias: An alias name for migration (for example the bitmap name on
686#     the opposite site).
687#
688# @transform: Allows the modification of the migrated bitmap.  (since
689#     6.0)
690#
691# Since: 5.2
692##
693{ 'struct': 'BitmapMigrationBitmapAlias',
694  'data': {
695      'name': 'str',
696      'alias': 'str',
697      '*transform': 'BitmapMigrationBitmapAliasTransform'
698  } }
699
700##
701# @BitmapMigrationNodeAlias:
702#
703# Maps a block node name and the bitmaps it has to aliases for dirty
704# bitmap migration.
705#
706# @node-name: A block node name.
707#
708# @alias: An alias block node name for migration (for example the node
709#     name on the opposite site).
710#
711# @bitmaps: Mappings for the bitmaps on this node.
712#
713# Since: 5.2
714##
715{ 'struct': 'BitmapMigrationNodeAlias',
716  'data': {
717      'node-name': 'str',
718      'alias': 'str',
719      'bitmaps': [ 'BitmapMigrationBitmapAlias' ]
720  } }
721
722##
723# @MigrationParameter:
724#
725# Migration parameters enumeration
726#
727# @announce-initial: Initial delay (in milliseconds) before sending
728#     the first announce (Since 4.0)
729#
730# @announce-max: Maximum delay (in milliseconds) between packets in
731#     the announcement (Since 4.0)
732#
733# @announce-rounds: Number of self-announce packets sent after
734#     migration (Since 4.0)
735#
736# @announce-step: Increase in delay (in milliseconds) between
737#     subsequent packets in the announcement (Since 4.0)
738#
739# @compress-level: Set the compression level to be used in live
740#     migration, the compression level is an integer between 0 and 9,
741#     where 0 means no compression, 1 means the best compression
742#     speed, and 9 means best compression ratio which will consume
743#     more CPU.
744#
745# @compress-threads: Set compression thread count to be used in live
746#     migration, the compression thread count is an integer between 1
747#     and 255.
748#
749# @compress-wait-thread: Controls behavior when all compression
750#     threads are currently busy.  If true (default), wait for a free
751#     compression thread to become available; otherwise, send the page
752#     uncompressed.  (Since 3.1)
753#
754# @decompress-threads: Set decompression thread count to be used in
755#     live migration, the decompression thread count is an integer
756#     between 1 and 255. Usually, decompression is at least 4 times as
757#     fast as compression, so set the decompress-threads to the number
758#     about 1/4 of compress-threads is adequate.
759#
760# @throttle-trigger-threshold: The ratio of bytes_dirty_period and
761#     bytes_xfer_period to trigger throttling.  It is expressed as
762#     percentage.  The default value is 50. (Since 5.0)
763#
764# @cpu-throttle-initial: Initial percentage of time guest cpus are
765#     throttled when migration auto-converge is activated.  The
766#     default value is 20. (Since 2.7)
767#
768# @cpu-throttle-increment: throttle percentage increase each time
769#     auto-converge detects that migration is not making progress.
770#     The default value is 10. (Since 2.7)
771#
772# @cpu-throttle-tailslow: Make CPU throttling slower at tail stage At
773#     the tail stage of throttling, the Guest is very sensitive to CPU
774#     percentage while the @cpu-throttle -increment is excessive
775#     usually at tail stage.  If this parameter is true, we will
776#     compute the ideal CPU percentage used by the Guest, which may
777#     exactly make the dirty rate match the dirty rate threshold.
778#     Then we will choose a smaller throttle increment between the one
779#     specified by @cpu-throttle-increment and the one generated by
780#     ideal CPU percentage.  Therefore, it is compatible to
781#     traditional throttling, meanwhile the throttle increment won't
782#     be excessive at tail stage.  The default value is false.  (Since
783#     5.1)
784#
785# @tls-creds: ID of the 'tls-creds' object that provides credentials
786#     for establishing a TLS connection over the migration data
787#     channel.  On the outgoing side of the migration, the credentials
788#     must be for a 'client' endpoint, while for the incoming side the
789#     credentials must be for a 'server' endpoint.  Setting this will
790#     enable TLS for all migrations.  The default is unset, resulting
791#     in unsecured migration at the QEMU level.  (Since 2.7)
792#
793# @tls-hostname: hostname of the target host for the migration.  This
794#     is required when using x509 based TLS credentials and the
795#     migration URI does not already include a hostname.  For example
796#     if using fd: or exec: based migration, the hostname must be
797#     provided so that the server's x509 certificate identity can be
798#     validated.  (Since 2.7)
799#
800# @tls-authz: ID of the 'authz' object subclass that provides access
801#     control checking of the TLS x509 certificate distinguished name.
802#     This object is only resolved at time of use, so can be deleted
803#     and recreated on the fly while the migration server is active.
804#     If missing, it will default to denying access (Since 4.0)
805#
806# @max-bandwidth: to set maximum speed for migration.  maximum speed
807#     in bytes per second.  (Since 2.8)
808#
809# @avail-switchover-bandwidth: to set the available bandwidth that
810#     migration can use during switchover phase.  NOTE!  This does not
811#     limit the bandwidth during switchover, but only for calculations when
812#     making decisions to switchover.  By default, this value is zero,
813#     which means QEMU will estimate the bandwidth automatically.  This can
814#     be set when the estimated value is not accurate, while the user is
815#     able to guarantee such bandwidth is available when switching over.
816#     When specified correctly, this can make the switchover decision much
817#     more accurate.  (Since 8.2)
818#
819# @downtime-limit: set maximum tolerated downtime for migration.
820#     maximum downtime in milliseconds (Since 2.8)
821#
822# @x-checkpoint-delay: The delay time (in ms) between two COLO
823#     checkpoints in periodic mode.  (Since 2.8)
824#
825# @block-incremental: Affects how much storage is migrated when the
826#     block migration capability is enabled.  When false, the entire
827#     storage backing chain is migrated into a flattened image at the
828#     destination; when true, only the active qcow2 layer is migrated
829#     and the destination must already have access to the same backing
830#     chain as was used on the source.  (since 2.10)
831#
832# @multifd-channels: Number of channels used to migrate data in
833#     parallel.  This is the same number that the number of sockets
834#     used for migration.  The default value is 2 (since 4.0)
835#
836# @xbzrle-cache-size: cache size to be used by XBZRLE migration.  It
837#     needs to be a multiple of the target page size and a power of 2
838#     (Since 2.11)
839#
840# @max-postcopy-bandwidth: Background transfer bandwidth during
841#     postcopy.  Defaults to 0 (unlimited).  In bytes per second.
842#     (Since 3.0)
843#
844# @max-cpu-throttle: maximum cpu throttle percentage.  Defaults to 99.
845#     (Since 3.1)
846#
847# @multifd-compression: Which compression method to use.  Defaults to
848#     none.  (Since 5.0)
849#
850# @multifd-zlib-level: Set the compression level to be used in live
851#     migration, the compression level is an integer between 0 and 9,
852#     where 0 means no compression, 1 means the best compression
853#     speed, and 9 means best compression ratio which will consume
854#     more CPU. Defaults to 1. (Since 5.0)
855#
856# @multifd-zstd-level: Set the compression level to be used in live
857#     migration, the compression level is an integer between 0 and 20,
858#     where 0 means no compression, 1 means the best compression
859#     speed, and 20 means best compression ratio which will consume
860#     more CPU. Defaults to 1. (Since 5.0)
861#
862# @block-bitmap-mapping: Maps block nodes and bitmaps on them to
863#     aliases for the purpose of dirty bitmap migration.  Such aliases
864#     may for example be the corresponding names on the opposite site.
865#     The mapping must be one-to-one, but not necessarily complete: On
866#     the source, unmapped bitmaps and all bitmaps on unmapped nodes
867#     will be ignored.  On the destination, encountering an unmapped
868#     alias in the incoming migration stream will result in a report,
869#     and all further bitmap migration data will then be discarded.
870#     Note that the destination does not know about bitmaps it does
871#     not receive, so there is no limitation or requirement regarding
872#     the number of bitmaps received, or how they are named, or on
873#     which nodes they are placed.  By default (when this parameter
874#     has never been set), bitmap names are mapped to themselves.
875#     Nodes are mapped to their block device name if there is one, and
876#     to their node name otherwise.  (Since 5.2)
877#
878# @x-vcpu-dirty-limit-period: Periodic time (in milliseconds) of dirty
879#     limit during live migration.  Should be in the range 1 to 1000ms.
880#     Defaults to 1000ms.  (Since 8.1)
881#
882# @vcpu-dirty-limit: Dirtyrate limit (MB/s) during live migration.
883#     Defaults to 1.  (Since 8.1)
884#
885# @mode: Migration mode. See description in @MigMode. Default is 'normal'.
886#        (Since 8.2)
887#
888# Features:
889#
890# @deprecated: Member @block-incremental is deprecated.  Use
891#     blockdev-mirror with NBD instead.  Members @compress-level,
892#     @compress-threads, @decompress-threads and @compress-wait-thread
893#     are deprecated because @compression is deprecated.
894#
895# @unstable: Members @x-checkpoint-delay and @x-vcpu-dirty-limit-period
896#     are experimental.
897#
898# Since: 2.4
899##
900{ 'enum': 'MigrationParameter',
901  'data': ['announce-initial', 'announce-max',
902           'announce-rounds', 'announce-step',
903           { 'name': 'compress-level', 'features': [ 'deprecated' ] },
904           { 'name': 'compress-threads', 'features': [ 'deprecated' ] },
905           { 'name': 'decompress-threads', 'features': [ 'deprecated' ] },
906           { 'name': 'compress-wait-thread', 'features': [ 'deprecated' ] },
907           'throttle-trigger-threshold',
908           'cpu-throttle-initial', 'cpu-throttle-increment',
909           'cpu-throttle-tailslow',
910           'tls-creds', 'tls-hostname', 'tls-authz', 'max-bandwidth',
911           'avail-switchover-bandwidth', 'downtime-limit',
912           { 'name': 'x-checkpoint-delay', 'features': [ 'unstable' ] },
913           { 'name': 'block-incremental', 'features': [ 'deprecated' ] },
914           'multifd-channels',
915           'xbzrle-cache-size', 'max-postcopy-bandwidth',
916           'max-cpu-throttle', 'multifd-compression',
917           'multifd-zlib-level', 'multifd-zstd-level',
918           'block-bitmap-mapping',
919           { 'name': 'x-vcpu-dirty-limit-period', 'features': ['unstable'] },
920           'vcpu-dirty-limit',
921           'mode'] }
922
923##
924# @MigrateSetParameters:
925#
926# @announce-initial: Initial delay (in milliseconds) before sending
927#     the first announce (Since 4.0)
928#
929# @announce-max: Maximum delay (in milliseconds) between packets in
930#     the announcement (Since 4.0)
931#
932# @announce-rounds: Number of self-announce packets sent after
933#     migration (Since 4.0)
934#
935# @announce-step: Increase in delay (in milliseconds) between
936#     subsequent packets in the announcement (Since 4.0)
937#
938# @compress-level: compression level
939#
940# @compress-threads: compression thread count
941#
942# @compress-wait-thread: Controls behavior when all compression
943#     threads are currently busy.  If true (default), wait for a free
944#     compression thread to become available; otherwise, send the page
945#     uncompressed.  (Since 3.1)
946#
947# @decompress-threads: decompression thread count
948#
949# @throttle-trigger-threshold: The ratio of bytes_dirty_period and
950#     bytes_xfer_period to trigger throttling.  It is expressed as
951#     percentage.  The default value is 50. (Since 5.0)
952#
953# @cpu-throttle-initial: Initial percentage of time guest cpus are
954#     throttled when migration auto-converge is activated.  The
955#     default value is 20. (Since 2.7)
956#
957# @cpu-throttle-increment: throttle percentage increase each time
958#     auto-converge detects that migration is not making progress.
959#     The default value is 10. (Since 2.7)
960#
961# @cpu-throttle-tailslow: Make CPU throttling slower at tail stage At
962#     the tail stage of throttling, the Guest is very sensitive to CPU
963#     percentage while the @cpu-throttle -increment is excessive
964#     usually at tail stage.  If this parameter is true, we will
965#     compute the ideal CPU percentage used by the Guest, which may
966#     exactly make the dirty rate match the dirty rate threshold.
967#     Then we will choose a smaller throttle increment between the one
968#     specified by @cpu-throttle-increment and the one generated by
969#     ideal CPU percentage.  Therefore, it is compatible to
970#     traditional throttling, meanwhile the throttle increment won't
971#     be excessive at tail stage.  The default value is false.  (Since
972#     5.1)
973#
974# @tls-creds: ID of the 'tls-creds' object that provides credentials
975#     for establishing a TLS connection over the migration data
976#     channel.  On the outgoing side of the migration, the credentials
977#     must be for a 'client' endpoint, while for the incoming side the
978#     credentials must be for a 'server' endpoint.  Setting this to a
979#     non-empty string enables TLS for all migrations.  An empty
980#     string means that QEMU will use plain text mode for migration,
981#     rather than TLS (Since 2.9) Previously (since 2.7), this was
982#     reported by omitting tls-creds instead.
983#
984# @tls-hostname: hostname of the target host for the migration.  This
985#     is required when using x509 based TLS credentials and the
986#     migration URI does not already include a hostname.  For example
987#     if using fd: or exec: based migration, the hostname must be
988#     provided so that the server's x509 certificate identity can be
989#     validated.  (Since 2.7) An empty string means that QEMU will use
990#     the hostname associated with the migration URI, if any.  (Since
991#     2.9) Previously (since 2.7), this was reported by omitting
992#     tls-hostname instead.
993#
994# @tls-authz: ID of the 'authz' object subclass that provides access
995#     control checking of the TLS x509 certificate distinguished name.
996#     (Since 4.0)
997#
998# @max-bandwidth: to set maximum speed for migration.  maximum speed
999#     in bytes per second.  (Since 2.8)
1000#
1001# @avail-switchover-bandwidth: to set the available bandwidth that
1002#     migration can use during switchover phase.  NOTE!  This does not
1003#     limit the bandwidth during switchover, but only for calculations when
1004#     making decisions to switchover.  By default, this value is zero,
1005#     which means QEMU will estimate the bandwidth automatically.  This can
1006#     be set when the estimated value is not accurate, while the user is
1007#     able to guarantee such bandwidth is available when switching over.
1008#     When specified correctly, this can make the switchover decision much
1009#     more accurate.  (Since 8.2)
1010#
1011# @downtime-limit: set maximum tolerated downtime for migration.
1012#     maximum downtime in milliseconds (Since 2.8)
1013#
1014# @x-checkpoint-delay: the delay time between two COLO checkpoints.
1015#     (Since 2.8)
1016#
1017# @block-incremental: Affects how much storage is migrated when the
1018#     block migration capability is enabled.  When false, the entire
1019#     storage backing chain is migrated into a flattened image at the
1020#     destination; when true, only the active qcow2 layer is migrated
1021#     and the destination must already have access to the same backing
1022#     chain as was used on the source.  (since 2.10)
1023#
1024# @multifd-channels: Number of channels used to migrate data in
1025#     parallel.  This is the same number that the number of sockets
1026#     used for migration.  The default value is 2 (since 4.0)
1027#
1028# @xbzrle-cache-size: cache size to be used by XBZRLE migration.  It
1029#     needs to be a multiple of the target page size and a power of 2
1030#     (Since 2.11)
1031#
1032# @max-postcopy-bandwidth: Background transfer bandwidth during
1033#     postcopy.  Defaults to 0 (unlimited).  In bytes per second.
1034#     (Since 3.0)
1035#
1036# @max-cpu-throttle: maximum cpu throttle percentage.  The default
1037#     value is 99. (Since 3.1)
1038#
1039# @multifd-compression: Which compression method to use.  Defaults to
1040#     none.  (Since 5.0)
1041#
1042# @multifd-zlib-level: Set the compression level to be used in live
1043#     migration, the compression level is an integer between 0 and 9,
1044#     where 0 means no compression, 1 means the best compression
1045#     speed, and 9 means best compression ratio which will consume
1046#     more CPU. Defaults to 1. (Since 5.0)
1047#
1048# @multifd-zstd-level: Set the compression level to be used in live
1049#     migration, the compression level is an integer between 0 and 20,
1050#     where 0 means no compression, 1 means the best compression
1051#     speed, and 20 means best compression ratio which will consume
1052#     more CPU. Defaults to 1. (Since 5.0)
1053#
1054# @block-bitmap-mapping: Maps block nodes and bitmaps on them to
1055#     aliases for the purpose of dirty bitmap migration.  Such aliases
1056#     may for example be the corresponding names on the opposite site.
1057#     The mapping must be one-to-one, but not necessarily complete: On
1058#     the source, unmapped bitmaps and all bitmaps on unmapped nodes
1059#     will be ignored.  On the destination, encountering an unmapped
1060#     alias in the incoming migration stream will result in a report,
1061#     and all further bitmap migration data will then be discarded.
1062#     Note that the destination does not know about bitmaps it does
1063#     not receive, so there is no limitation or requirement regarding
1064#     the number of bitmaps received, or how they are named, or on
1065#     which nodes they are placed.  By default (when this parameter
1066#     has never been set), bitmap names are mapped to themselves.
1067#     Nodes are mapped to their block device name if there is one, and
1068#     to their node name otherwise.  (Since 5.2)
1069#
1070# @x-vcpu-dirty-limit-period: Periodic time (in milliseconds) of dirty
1071#     limit during live migration.  Should be in the range 1 to 1000ms.
1072#     Defaults to 1000ms.  (Since 8.1)
1073#
1074# @vcpu-dirty-limit: Dirtyrate limit (MB/s) during live migration.
1075#     Defaults to 1.  (Since 8.1)
1076#
1077# @mode: Migration mode. See description in @MigMode. Default is 'normal'.
1078#        (Since 8.2)
1079#
1080# Features:
1081#
1082# @deprecated: Member @block-incremental is deprecated.  Use
1083#     blockdev-mirror with NBD instead.  Members @compress-level,
1084#     @compress-threads, @decompress-threads and @compress-wait-thread
1085#     are deprecated because @compression is deprecated.
1086#
1087# @unstable: Members @x-checkpoint-delay and @x-vcpu-dirty-limit-period
1088#     are experimental.
1089#
1090# TODO: either fuse back into MigrationParameters, or make
1091#     MigrationParameters members mandatory
1092#
1093# Since: 2.4
1094##
1095{ 'struct': 'MigrateSetParameters',
1096  'data': { '*announce-initial': 'size',
1097            '*announce-max': 'size',
1098            '*announce-rounds': 'size',
1099            '*announce-step': 'size',
1100            '*compress-level': { 'type': 'uint8',
1101                                 'features': [ 'deprecated' ] },
1102            '*compress-threads':  { 'type': 'uint8',
1103                                    'features': [ 'deprecated' ] },
1104            '*compress-wait-thread':  { 'type': 'bool',
1105                                        'features': [ 'deprecated' ] },
1106            '*decompress-threads':  { 'type': 'uint8',
1107                                      'features': [ 'deprecated' ] },
1108            '*throttle-trigger-threshold': 'uint8',
1109            '*cpu-throttle-initial': 'uint8',
1110            '*cpu-throttle-increment': 'uint8',
1111            '*cpu-throttle-tailslow': 'bool',
1112            '*tls-creds': 'StrOrNull',
1113            '*tls-hostname': 'StrOrNull',
1114            '*tls-authz': 'StrOrNull',
1115            '*max-bandwidth': 'size',
1116            '*avail-switchover-bandwidth': 'size',
1117            '*downtime-limit': 'uint64',
1118            '*x-checkpoint-delay': { 'type': 'uint32',
1119                                     'features': [ 'unstable' ] },
1120            '*block-incremental': { 'type': 'bool',
1121                                    'features': [ 'deprecated' ] },
1122            '*multifd-channels': 'uint8',
1123            '*xbzrle-cache-size': 'size',
1124            '*max-postcopy-bandwidth': 'size',
1125            '*max-cpu-throttle': 'uint8',
1126            '*multifd-compression': 'MultiFDCompression',
1127            '*multifd-zlib-level': 'uint8',
1128            '*multifd-zstd-level': 'uint8',
1129            '*block-bitmap-mapping': [ 'BitmapMigrationNodeAlias' ],
1130            '*x-vcpu-dirty-limit-period': { 'type': 'uint64',
1131                                            'features': [ 'unstable' ] },
1132            '*vcpu-dirty-limit': 'uint64',
1133            '*mode': 'MigMode'} }
1134
1135##
1136# @migrate-set-parameters:
1137#
1138# Set various migration parameters.
1139#
1140# Since: 2.4
1141#
1142# Example:
1143#
1144#     -> { "execute": "migrate-set-parameters" ,
1145#          "arguments": { "multifd-channels": 5 } }
1146#     <- { "return": {} }
1147##
1148{ 'command': 'migrate-set-parameters', 'boxed': true,
1149  'data': 'MigrateSetParameters' }
1150
1151##
1152# @MigrationParameters:
1153#
1154# The optional members aren't actually optional.
1155#
1156# @announce-initial: Initial delay (in milliseconds) before sending
1157#     the first announce (Since 4.0)
1158#
1159# @announce-max: Maximum delay (in milliseconds) between packets in
1160#     the announcement (Since 4.0)
1161#
1162# @announce-rounds: Number of self-announce packets sent after
1163#     migration (Since 4.0)
1164#
1165# @announce-step: Increase in delay (in milliseconds) between
1166#     subsequent packets in the announcement (Since 4.0)
1167#
1168# @compress-level: compression level
1169#
1170# @compress-threads: compression thread count
1171#
1172# @compress-wait-thread: Controls behavior when all compression
1173#     threads are currently busy.  If true (default), wait for a free
1174#     compression thread to become available; otherwise, send the page
1175#     uncompressed.  (Since 3.1)
1176#
1177# @decompress-threads: decompression thread count
1178#
1179# @throttle-trigger-threshold: The ratio of bytes_dirty_period and
1180#     bytes_xfer_period to trigger throttling.  It is expressed as
1181#     percentage.  The default value is 50. (Since 5.0)
1182#
1183# @cpu-throttle-initial: Initial percentage of time guest cpus are
1184#     throttled when migration auto-converge is activated.  (Since
1185#     2.7)
1186#
1187# @cpu-throttle-increment: throttle percentage increase each time
1188#     auto-converge detects that migration is not making progress.
1189#     (Since 2.7)
1190#
1191# @cpu-throttle-tailslow: Make CPU throttling slower at tail stage At
1192#     the tail stage of throttling, the Guest is very sensitive to CPU
1193#     percentage while the @cpu-throttle -increment is excessive
1194#     usually at tail stage.  If this parameter is true, we will
1195#     compute the ideal CPU percentage used by the Guest, which may
1196#     exactly make the dirty rate match the dirty rate threshold.
1197#     Then we will choose a smaller throttle increment between the one
1198#     specified by @cpu-throttle-increment and the one generated by
1199#     ideal CPU percentage.  Therefore, it is compatible to
1200#     traditional throttling, meanwhile the throttle increment won't
1201#     be excessive at tail stage.  The default value is false.  (Since
1202#     5.1)
1203#
1204# @tls-creds: ID of the 'tls-creds' object that provides credentials
1205#     for establishing a TLS connection over the migration data
1206#     channel.  On the outgoing side of the migration, the credentials
1207#     must be for a 'client' endpoint, while for the incoming side the
1208#     credentials must be for a 'server' endpoint.  An empty string
1209#     means that QEMU will use plain text mode for migration, rather
1210#     than TLS (Since 2.7) Note: 2.8 reports this by omitting
1211#     tls-creds instead.
1212#
1213# @tls-hostname: hostname of the target host for the migration.  This
1214#     is required when using x509 based TLS credentials and the
1215#     migration URI does not already include a hostname.  For example
1216#     if using fd: or exec: based migration, the hostname must be
1217#     provided so that the server's x509 certificate identity can be
1218#     validated.  (Since 2.7) An empty string means that QEMU will use
1219#     the hostname associated with the migration URI, if any.  (Since
1220#     2.9) Note: 2.8 reports this by omitting tls-hostname instead.
1221#
1222# @tls-authz: ID of the 'authz' object subclass that provides access
1223#     control checking of the TLS x509 certificate distinguished name.
1224#     (Since 4.0)
1225#
1226# @max-bandwidth: to set maximum speed for migration.  maximum speed
1227#     in bytes per second.  (Since 2.8)
1228#
1229# @avail-switchover-bandwidth: to set the available bandwidth that
1230#     migration can use during switchover phase.  NOTE!  This does not
1231#     limit the bandwidth during switchover, but only for calculations when
1232#     making decisions to switchover.  By default, this value is zero,
1233#     which means QEMU will estimate the bandwidth automatically.  This can
1234#     be set when the estimated value is not accurate, while the user is
1235#     able to guarantee such bandwidth is available when switching over.
1236#     When specified correctly, this can make the switchover decision much
1237#     more accurate.  (Since 8.2)
1238#
1239# @downtime-limit: set maximum tolerated downtime for migration.
1240#     maximum downtime in milliseconds (Since 2.8)
1241#
1242# @x-checkpoint-delay: the delay time between two COLO checkpoints.
1243#     (Since 2.8)
1244#
1245# @block-incremental: Affects how much storage is migrated when the
1246#     block migration capability is enabled.  When false, the entire
1247#     storage backing chain is migrated into a flattened image at the
1248#     destination; when true, only the active qcow2 layer is migrated
1249#     and the destination must already have access to the same backing
1250#     chain as was used on the source.  (since 2.10)
1251#
1252# @multifd-channels: Number of channels used to migrate data in
1253#     parallel.  This is the same number that the number of sockets
1254#     used for migration.  The default value is 2 (since 4.0)
1255#
1256# @xbzrle-cache-size: cache size to be used by XBZRLE migration.  It
1257#     needs to be a multiple of the target page size and a power of 2
1258#     (Since 2.11)
1259#
1260# @max-postcopy-bandwidth: Background transfer bandwidth during
1261#     postcopy.  Defaults to 0 (unlimited).  In bytes per second.
1262#     (Since 3.0)
1263#
1264# @max-cpu-throttle: maximum cpu throttle percentage.  Defaults to 99.
1265#     (Since 3.1)
1266#
1267# @multifd-compression: Which compression method to use.  Defaults to
1268#     none.  (Since 5.0)
1269#
1270# @multifd-zlib-level: Set the compression level to be used in live
1271#     migration, the compression level is an integer between 0 and 9,
1272#     where 0 means no compression, 1 means the best compression
1273#     speed, and 9 means best compression ratio which will consume
1274#     more CPU. Defaults to 1. (Since 5.0)
1275#
1276# @multifd-zstd-level: Set the compression level to be used in live
1277#     migration, the compression level is an integer between 0 and 20,
1278#     where 0 means no compression, 1 means the best compression
1279#     speed, and 20 means best compression ratio which will consume
1280#     more CPU. Defaults to 1. (Since 5.0)
1281#
1282# @block-bitmap-mapping: Maps block nodes and bitmaps on them to
1283#     aliases for the purpose of dirty bitmap migration.  Such aliases
1284#     may for example be the corresponding names on the opposite site.
1285#     The mapping must be one-to-one, but not necessarily complete: On
1286#     the source, unmapped bitmaps and all bitmaps on unmapped nodes
1287#     will be ignored.  On the destination, encountering an unmapped
1288#     alias in the incoming migration stream will result in a report,
1289#     and all further bitmap migration data will then be discarded.
1290#     Note that the destination does not know about bitmaps it does
1291#     not receive, so there is no limitation or requirement regarding
1292#     the number of bitmaps received, or how they are named, or on
1293#     which nodes they are placed.  By default (when this parameter
1294#     has never been set), bitmap names are mapped to themselves.
1295#     Nodes are mapped to their block device name if there is one, and
1296#     to their node name otherwise.  (Since 5.2)
1297#
1298# @x-vcpu-dirty-limit-period: Periodic time (in milliseconds) of dirty
1299#     limit during live migration.  Should be in the range 1 to 1000ms.
1300#     Defaults to 1000ms.  (Since 8.1)
1301#
1302# @vcpu-dirty-limit: Dirtyrate limit (MB/s) during live migration.
1303#     Defaults to 1.  (Since 8.1)
1304#
1305# @mode: Migration mode. See description in @MigMode. Default is 'normal'.
1306#        (Since 8.2)
1307#
1308# Features:
1309#
1310# @deprecated: Member @block-incremental is deprecated.  Use
1311#     blockdev-mirror with NBD instead.  Members @compress-level,
1312#     @compress-threads, @decompress-threads and @compress-wait-thread
1313#     are deprecated because @compression is deprecated.
1314#
1315# @unstable: Members @x-checkpoint-delay and @x-vcpu-dirty-limit-period
1316#     are experimental.
1317#
1318# Since: 2.4
1319##
1320{ 'struct': 'MigrationParameters',
1321  'data': { '*announce-initial': 'size',
1322            '*announce-max': 'size',
1323            '*announce-rounds': 'size',
1324            '*announce-step': 'size',
1325            '*compress-level': { 'type': 'uint8',
1326                                 'features': [ 'deprecated' ] },
1327            '*compress-threads': { 'type': 'uint8',
1328                                   'features': [ 'deprecated' ] },
1329            '*compress-wait-thread': { 'type': 'bool',
1330                                       'features': [ 'deprecated' ] },
1331            '*decompress-threads': { 'type': 'uint8',
1332                                     'features': [ 'deprecated' ] },
1333            '*throttle-trigger-threshold': 'uint8',
1334            '*cpu-throttle-initial': 'uint8',
1335            '*cpu-throttle-increment': 'uint8',
1336            '*cpu-throttle-tailslow': 'bool',
1337            '*tls-creds': 'str',
1338            '*tls-hostname': 'str',
1339            '*tls-authz': 'str',
1340            '*max-bandwidth': 'size',
1341            '*avail-switchover-bandwidth': 'size',
1342            '*downtime-limit': 'uint64',
1343            '*x-checkpoint-delay': { 'type': 'uint32',
1344                                     'features': [ 'unstable' ] },
1345            '*block-incremental': { 'type': 'bool',
1346                                    'features': [ 'deprecated' ] },
1347            '*multifd-channels': 'uint8',
1348            '*xbzrle-cache-size': 'size',
1349            '*max-postcopy-bandwidth': 'size',
1350            '*max-cpu-throttle': 'uint8',
1351            '*multifd-compression': 'MultiFDCompression',
1352            '*multifd-zlib-level': 'uint8',
1353            '*multifd-zstd-level': 'uint8',
1354            '*block-bitmap-mapping': [ 'BitmapMigrationNodeAlias' ],
1355            '*x-vcpu-dirty-limit-period': { 'type': 'uint64',
1356                                            'features': [ 'unstable' ] },
1357            '*vcpu-dirty-limit': 'uint64',
1358            '*mode': 'MigMode'} }
1359
1360##
1361# @query-migrate-parameters:
1362#
1363# Returns information about the current migration parameters
1364#
1365# Returns: @MigrationParameters
1366#
1367# Since: 2.4
1368#
1369# Example:
1370#
1371#     -> { "execute": "query-migrate-parameters" }
1372#     <- { "return": {
1373#              "multifd-channels": 2,
1374#              "cpu-throttle-increment": 10,
1375#              "cpu-throttle-initial": 20,
1376#              "max-bandwidth": 33554432,
1377#              "downtime-limit": 300
1378#           }
1379#        }
1380##
1381{ 'command': 'query-migrate-parameters',
1382  'returns': 'MigrationParameters' }
1383
1384##
1385# @migrate-start-postcopy:
1386#
1387# Followup to a migration command to switch the migration to postcopy
1388# mode.  The postcopy-ram capability must be set on both source and
1389# destination before the original migration command.
1390#
1391# Since: 2.5
1392#
1393# Example:
1394#
1395#     -> { "execute": "migrate-start-postcopy" }
1396#     <- { "return": {} }
1397##
1398{ 'command': 'migrate-start-postcopy' }
1399
1400##
1401# @MIGRATION:
1402#
1403# Emitted when a migration event happens
1404#
1405# @status: @MigrationStatus describing the current migration status.
1406#
1407# Since: 2.4
1408#
1409# Example:
1410#
1411#     <- {"timestamp": {"seconds": 1432121972, "microseconds": 744001},
1412#         "event": "MIGRATION",
1413#         "data": {"status": "completed"} }
1414##
1415{ 'event': 'MIGRATION',
1416  'data': {'status': 'MigrationStatus'}}
1417
1418##
1419# @MIGRATION_PASS:
1420#
1421# Emitted from the source side of a migration at the start of each
1422# pass (when it syncs the dirty bitmap)
1423#
1424# @pass: An incrementing count (starting at 1 on the first pass)
1425#
1426# Since: 2.6
1427#
1428# Example:
1429#
1430#     <- { "timestamp": {"seconds": 1449669631, "microseconds": 239225},
1431#           "event": "MIGRATION_PASS", "data": {"pass": 2} }
1432##
1433{ 'event': 'MIGRATION_PASS',
1434  'data': { 'pass': 'int' } }
1435
1436##
1437# @COLOMessage:
1438#
1439# The message transmission between Primary side and Secondary side.
1440#
1441# @checkpoint-ready: Secondary VM (SVM) is ready for checkpointing
1442#
1443# @checkpoint-request: Primary VM (PVM) tells SVM to prepare for
1444#     checkpointing
1445#
1446# @checkpoint-reply: SVM gets PVM's checkpoint request
1447#
1448# @vmstate-send: VM's state will be sent by PVM.
1449#
1450# @vmstate-size: The total size of VMstate.
1451#
1452# @vmstate-received: VM's state has been received by SVM.
1453#
1454# @vmstate-loaded: VM's state has been loaded by SVM.
1455#
1456# Since: 2.8
1457##
1458{ 'enum': 'COLOMessage',
1459  'data': [ 'checkpoint-ready', 'checkpoint-request', 'checkpoint-reply',
1460            'vmstate-send', 'vmstate-size', 'vmstate-received',
1461            'vmstate-loaded' ] }
1462
1463##
1464# @COLOMode:
1465#
1466# The COLO current mode.
1467#
1468# @none: COLO is disabled.
1469#
1470# @primary: COLO node in primary side.
1471#
1472# @secondary: COLO node in slave side.
1473#
1474# Since: 2.8
1475##
1476{ 'enum': 'COLOMode',
1477  'data': [ 'none', 'primary', 'secondary'] }
1478
1479##
1480# @FailoverStatus:
1481#
1482# An enumeration of COLO failover status
1483#
1484# @none: no failover has ever happened
1485#
1486# @require: got failover requirement but not handled
1487#
1488# @active: in the process of doing failover
1489#
1490# @completed: finish the process of failover
1491#
1492# @relaunch: restart the failover process, from 'none' -> 'completed'
1493#     (Since 2.9)
1494#
1495# Since: 2.8
1496##
1497{ 'enum': 'FailoverStatus',
1498  'data': [ 'none', 'require', 'active', 'completed', 'relaunch' ] }
1499
1500##
1501# @COLO_EXIT:
1502#
1503# Emitted when VM finishes COLO mode due to some errors happening or
1504# at the request of users.
1505#
1506# @mode: report COLO mode when COLO exited.
1507#
1508# @reason: describes the reason for the COLO exit.
1509#
1510# Since: 3.1
1511#
1512# Example:
1513#
1514#     <- { "timestamp": {"seconds": 2032141960, "microseconds": 417172},
1515#          "event": "COLO_EXIT", "data": {"mode": "primary", "reason": "request" } }
1516##
1517{ 'event': 'COLO_EXIT',
1518  'data': {'mode': 'COLOMode', 'reason': 'COLOExitReason' } }
1519
1520##
1521# @COLOExitReason:
1522#
1523# The reason for a COLO exit.
1524#
1525# @none: failover has never happened.  This state does not occur in
1526#     the COLO_EXIT event, and is only visible in the result of
1527#     query-colo-status.
1528#
1529# @request: COLO exit is due to an external request.
1530#
1531# @error: COLO exit is due to an internal error.
1532#
1533# @processing: COLO is currently handling a failover (since 4.0).
1534#
1535# Since: 3.1
1536##
1537{ 'enum': 'COLOExitReason',
1538  'data': [ 'none', 'request', 'error' , 'processing' ] }
1539
1540##
1541# @x-colo-lost-heartbeat:
1542#
1543# Tell qemu that heartbeat is lost, request it to do takeover
1544# procedures.  If this command is sent to the PVM, the Primary side
1545# will exit COLO mode.  If sent to the Secondary, the Secondary side
1546# will run failover work, then takes over server operation to become
1547# the service VM.
1548#
1549# Features:
1550#
1551# @unstable: This command is experimental.
1552#
1553# Since: 2.8
1554#
1555# Example:
1556#
1557#     -> { "execute": "x-colo-lost-heartbeat" }
1558#     <- { "return": {} }
1559##
1560{ 'command': 'x-colo-lost-heartbeat',
1561  'features': [ 'unstable' ],
1562  'if': 'CONFIG_REPLICATION' }
1563
1564##
1565# @migrate_cancel:
1566#
1567# Cancel the current executing migration process.
1568#
1569# Returns: nothing on success
1570#
1571# Notes: This command succeeds even if there is no migration process
1572#     running.
1573#
1574# Since: 0.14
1575#
1576# Example:
1577#
1578#     -> { "execute": "migrate_cancel" }
1579#     <- { "return": {} }
1580##
1581{ 'command': 'migrate_cancel' }
1582
1583##
1584# @migrate-continue:
1585#
1586# Continue migration when it's in a paused state.
1587#
1588# @state: The state the migration is currently expected to be in
1589#
1590# Returns: nothing on success
1591#
1592# Since: 2.11
1593#
1594# Example:
1595#
1596#     -> { "execute": "migrate-continue" , "arguments":
1597#          { "state": "pre-switchover" } }
1598#     <- { "return": {} }
1599##
1600{ 'command': 'migrate-continue', 'data': {'state': 'MigrationStatus'} }
1601
1602##
1603# @MigrationAddressType:
1604#
1605# The migration stream transport mechanisms.
1606#
1607# @socket: Migrate via socket.
1608#
1609# @exec: Direct the migration stream to another process.
1610#
1611# @rdma: Migrate via RDMA.
1612#
1613# @file: Direct the migration stream to a file.
1614#
1615# Since: 8.2
1616##
1617{ 'enum': 'MigrationAddressType',
1618  'data': [ 'socket', 'exec', 'rdma', 'file' ] }
1619
1620##
1621# @FileMigrationArgs:
1622#
1623# @filename: The file to receive the migration stream
1624#
1625# @offset: The file offset where the migration stream will start
1626#
1627# Since: 8.2
1628##
1629{ 'struct': 'FileMigrationArgs',
1630  'data': { 'filename': 'str',
1631            'offset': 'uint64' } }
1632
1633##
1634# @MigrationExecCommand:
1635#
1636# @args: command (list head) and arguments to execute.
1637#
1638# Since: 8.2
1639##
1640{ 'struct': 'MigrationExecCommand',
1641  'data': {'args': [ 'str' ] } }
1642
1643##
1644# @MigrationAddress:
1645#
1646# Migration endpoint configuration.
1647#
1648# @transport: The migration stream transport mechanism
1649#
1650# Since: 8.2
1651##
1652{ 'union': 'MigrationAddress',
1653  'base': { 'transport' : 'MigrationAddressType'},
1654  'discriminator': 'transport',
1655  'data': {
1656    'socket': 'SocketAddress',
1657    'exec': 'MigrationExecCommand',
1658    'rdma': 'InetSocketAddress',
1659    'file': 'FileMigrationArgs' } }
1660
1661##
1662# @MigrationChannelType:
1663#
1664# The migration channel-type request options.
1665#
1666# @main: Main outbound migration channel.
1667#
1668# Since: 8.1
1669##
1670{ 'enum': 'MigrationChannelType',
1671  'data': [ 'main' ] }
1672
1673##
1674# @MigrationChannel:
1675#
1676# Migration stream channel parameters.
1677#
1678# @channel-type: Channel type for transferring packet information.
1679#
1680# @addr: Migration endpoint configuration on destination interface.
1681#
1682# Since: 8.1
1683##
1684{ 'struct': 'MigrationChannel',
1685  'data': {
1686      'channel-type': 'MigrationChannelType',
1687      'addr': 'MigrationAddress' } }
1688
1689##
1690# @migrate:
1691#
1692# Migrates the current running guest to another Virtual Machine.
1693#
1694# @uri: the Uniform Resource Identifier of the destination VM
1695#
1696# @channels: list of migration stream channels with each stream in the
1697#     list connected to a destination interface endpoint.
1698#
1699# @blk: do block migration (full disk copy)
1700#
1701# @inc: incremental disk copy migration
1702#
1703# @detach: this argument exists only for compatibility reasons and is
1704#     ignored by QEMU
1705#
1706# @resume: resume one paused migration, default "off". (since 3.0)
1707#
1708# Features:
1709#
1710# @deprecated: Members @inc and @blk are deprecated.  Use
1711#     blockdev-mirror with NBD instead.
1712#
1713# Returns: nothing on success
1714#
1715# Since: 0.14
1716#
1717# Notes:
1718#
1719#     1. The 'query-migrate' command should be used to check
1720#        migration's progress and final result (this information is
1721#        provided by the 'status' member)
1722#
1723#     2. All boolean arguments default to false
1724#
1725#     3. The user Monitor's "detach" argument is invalid in QMP and
1726#        should not be used
1727#
1728#     4. The uri argument should have the Uniform Resource Identifier
1729#        of default destination VM. This connection will be bound to
1730#        default network.
1731#
1732#     5. For now, number of migration streams is restricted to one,
1733#        i.e number of items in 'channels' list is just 1.
1734#
1735#     6. The 'uri' and 'channels' arguments are mutually exclusive;
1736#        exactly one of the two should be present.
1737#
1738# Example:
1739#
1740#     -> { "execute": "migrate", "arguments": { "uri": "tcp:0:4446" } }
1741#     <- { "return": {} }
1742#
1743#     -> { "execute": "migrate",
1744#          "arguments": {
1745#              "channels": [ { "channel-type": "main",
1746#                              "addr": { "transport": "socket",
1747#                                        "type": "inet",
1748#                                        "host": "10.12.34.9",
1749#                                        "port": "1050" } } ] } }
1750#     <- { "return": {} }
1751#
1752#     -> { "execute": "migrate",
1753#          "arguments": {
1754#              "channels": [ { "channel-type": "main",
1755#                              "addr": { "transport": "exec",
1756#                                        "args": [ "/bin/nc", "-p", "6000",
1757#                                                  "/some/sock" ] } } ] } }
1758#     <- { "return": {} }
1759#
1760#     -> { "execute": "migrate",
1761#          "arguments": {
1762#              "channels": [ { "channel-type": "main",
1763#                              "addr": { "transport": "rdma",
1764#                                        "host": "10.12.34.9",
1765#                                        "port": "1050" } } ] } }
1766#     <- { "return": {} }
1767#
1768#     -> { "execute": "migrate",
1769#          "arguments": {
1770#              "channels": [ { "channel-type": "main",
1771#                              "addr": { "transport": "file",
1772#                                        "filename": "/tmp/migfile",
1773#                                        "offset": "0x1000" } } ] } }
1774#     <- { "return": {} }
1775#
1776##
1777{ 'command': 'migrate',
1778  'data': {'*uri': 'str',
1779           '*channels': [ 'MigrationChannel' ],
1780           '*blk': { 'type': 'bool', 'features': [ 'deprecated' ] },
1781           '*inc': { 'type': 'bool', 'features': [ 'deprecated' ] },
1782           '*detach': 'bool', '*resume': 'bool' } }
1783
1784##
1785# @migrate-incoming:
1786#
1787# Start an incoming migration, the qemu must have been started with
1788# -incoming defer
1789#
1790# @uri: The Uniform Resource Identifier identifying the source or
1791#     address to listen on
1792#
1793# @channels: list of migration stream channels with each stream in the
1794#     list connected to a destination interface endpoint.
1795#
1796# Returns: nothing on success
1797#
1798# Since: 2.3
1799#
1800# Notes:
1801#
1802#     1. It's a bad idea to use a string for the uri, but it needs to
1803#        stay compatible with -incoming and the format of the uri is
1804#        already exposed above libvirt.
1805#
1806#     2. QEMU must be started with -incoming defer to allow
1807#        migrate-incoming to be used.
1808#
1809#     3. The uri format is the same as for -incoming
1810#
1811#     4. For now, number of migration streams is restricted to one,
1812#        i.e number of items in 'channels' list is just 1.
1813#
1814#     5. The 'uri' and 'channels' arguments are mutually exclusive;
1815#        exactly one of the two should be present.
1816#
1817# Example:
1818#
1819#     -> { "execute": "migrate-incoming",
1820#          "arguments": { "uri": "tcp:0:4446" } }
1821#     <- { "return": {} }
1822#
1823#     -> { "execute": "migrate-incoming",
1824#          "arguments": {
1825#              "channels": [ { "channel-type": "main",
1826#                              "addr": { "transport": "socket",
1827#                                        "type": "inet",
1828#                                        "host": "10.12.34.9",
1829#                                        "port": "1050" } } ] } }
1830#     <- { "return": {} }
1831#
1832#     -> { "execute": "migrate-incoming",
1833#          "arguments": {
1834#              "channels": [ { "channel-type": "main",
1835#                              "addr": { "transport": "exec",
1836#                                        "args": [ "/bin/nc", "-p", "6000",
1837#                                                  "/some/sock" ] } } ] } }
1838#     <- { "return": {} }
1839#
1840#     -> { "execute": "migrate-incoming",
1841#          "arguments": {
1842#              "channels": [ { "channel-type": "main",
1843#                              "addr": { "transport": "rdma",
1844#                                        "host": "10.12.34.9",
1845#                                        "port": "1050" } } ] } }
1846#     <- { "return": {} }
1847##
1848{ 'command': 'migrate-incoming',
1849             'data': {'*uri': 'str',
1850                      '*channels': [ 'MigrationChannel' ] } }
1851
1852##
1853# @xen-save-devices-state:
1854#
1855# Save the state of all devices to file.  The RAM and the block
1856# devices of the VM are not saved by this command.
1857#
1858# @filename: the file to save the state of the devices to as binary
1859#     data.  See xen-save-devices-state.txt for a description of the
1860#     binary format.
1861#
1862# @live: Optional argument to ask QEMU to treat this command as part
1863#     of a live migration.  Default to true.  (since 2.11)
1864#
1865# Returns: Nothing on success
1866#
1867# Since: 1.1
1868#
1869# Example:
1870#
1871#     -> { "execute": "xen-save-devices-state",
1872#          "arguments": { "filename": "/tmp/save" } }
1873#     <- { "return": {} }
1874##
1875{ 'command': 'xen-save-devices-state',
1876  'data': {'filename': 'str', '*live':'bool' } }
1877
1878##
1879# @xen-set-global-dirty-log:
1880#
1881# Enable or disable the global dirty log mode.
1882#
1883# @enable: true to enable, false to disable.
1884#
1885# Returns: nothing
1886#
1887# Since: 1.3
1888#
1889# Example:
1890#
1891#     -> { "execute": "xen-set-global-dirty-log",
1892#          "arguments": { "enable": true } }
1893#     <- { "return": {} }
1894##
1895{ 'command': 'xen-set-global-dirty-log', 'data': { 'enable': 'bool' } }
1896
1897##
1898# @xen-load-devices-state:
1899#
1900# Load the state of all devices from file.  The RAM and the block
1901# devices of the VM are not loaded by this command.
1902#
1903# @filename: the file to load the state of the devices from as binary
1904#     data.  See xen-save-devices-state.txt for a description of the
1905#     binary format.
1906#
1907# Since: 2.7
1908#
1909# Example:
1910#
1911#     -> { "execute": "xen-load-devices-state",
1912#          "arguments": { "filename": "/tmp/resume" } }
1913#     <- { "return": {} }
1914##
1915{ 'command': 'xen-load-devices-state', 'data': {'filename': 'str'} }
1916
1917##
1918# @xen-set-replication:
1919#
1920# Enable or disable replication.
1921#
1922# @enable: true to enable, false to disable.
1923#
1924# @primary: true for primary or false for secondary.
1925#
1926# @failover: true to do failover, false to stop.  but cannot be
1927#     specified if 'enable' is true.  default value is false.
1928#
1929# Returns: nothing.
1930#
1931# Example:
1932#
1933#     -> { "execute": "xen-set-replication",
1934#          "arguments": {"enable": true, "primary": false} }
1935#     <- { "return": {} }
1936#
1937# Since: 2.9
1938##
1939{ 'command': 'xen-set-replication',
1940  'data': { 'enable': 'bool', 'primary': 'bool', '*failover': 'bool' },
1941  'if': 'CONFIG_REPLICATION' }
1942
1943##
1944# @ReplicationStatus:
1945#
1946# The result format for 'query-xen-replication-status'.
1947#
1948# @error: true if an error happened, false if replication is normal.
1949#
1950# @desc: the human readable error description string, when @error is
1951#     'true'.
1952#
1953# Since: 2.9
1954##
1955{ 'struct': 'ReplicationStatus',
1956  'data': { 'error': 'bool', '*desc': 'str' },
1957  'if': 'CONFIG_REPLICATION' }
1958
1959##
1960# @query-xen-replication-status:
1961#
1962# Query replication status while the vm is running.
1963#
1964# Returns: A @ReplicationStatus object showing the status.
1965#
1966# Example:
1967#
1968#     -> { "execute": "query-xen-replication-status" }
1969#     <- { "return": { "error": false } }
1970#
1971# Since: 2.9
1972##
1973{ 'command': 'query-xen-replication-status',
1974  'returns': 'ReplicationStatus',
1975  'if': 'CONFIG_REPLICATION' }
1976
1977##
1978# @xen-colo-do-checkpoint:
1979#
1980# Xen uses this command to notify replication to trigger a checkpoint.
1981#
1982# Returns: nothing.
1983#
1984# Example:
1985#
1986#     -> { "execute": "xen-colo-do-checkpoint" }
1987#     <- { "return": {} }
1988#
1989# Since: 2.9
1990##
1991{ 'command': 'xen-colo-do-checkpoint',
1992  'if': 'CONFIG_REPLICATION' }
1993
1994##
1995# @COLOStatus:
1996#
1997# The result format for 'query-colo-status'.
1998#
1999# @mode: COLO running mode.  If COLO is running, this field will
2000#     return 'primary' or 'secondary'.
2001#
2002# @last-mode: COLO last running mode.  If COLO is running, this field
2003#     will return same like mode field, after failover we can use this
2004#     field to get last colo mode.  (since 4.0)
2005#
2006# @reason: describes the reason for the COLO exit.
2007#
2008# Since: 3.1
2009##
2010{ 'struct': 'COLOStatus',
2011  'data': { 'mode': 'COLOMode', 'last-mode': 'COLOMode',
2012            'reason': 'COLOExitReason' },
2013  'if': 'CONFIG_REPLICATION' }
2014
2015##
2016# @query-colo-status:
2017#
2018# Query COLO status while the vm is running.
2019#
2020# Returns: A @COLOStatus object showing the status.
2021#
2022# Example:
2023#
2024#     -> { "execute": "query-colo-status" }
2025#     <- { "return": { "mode": "primary", "last-mode": "none", "reason": "request" } }
2026#
2027# Since: 3.1
2028##
2029{ 'command': 'query-colo-status',
2030  'returns': 'COLOStatus',
2031  'if': 'CONFIG_REPLICATION' }
2032
2033##
2034# @migrate-recover:
2035#
2036# Provide a recovery migration stream URI.
2037#
2038# @uri: the URI to be used for the recovery of migration stream.
2039#
2040# Returns: nothing.
2041#
2042# Example:
2043#
2044#     -> { "execute": "migrate-recover",
2045#          "arguments": { "uri": "tcp:192.168.1.200:12345" } }
2046#     <- { "return": {} }
2047#
2048# Since: 3.0
2049##
2050{ 'command': 'migrate-recover',
2051  'data': { 'uri': 'str' },
2052  'allow-oob': true }
2053
2054##
2055# @migrate-pause:
2056#
2057# Pause a migration.  Currently it only supports postcopy.
2058#
2059# Returns: nothing.
2060#
2061# Example:
2062#
2063#     -> { "execute": "migrate-pause" }
2064#     <- { "return": {} }
2065#
2066# Since: 3.0
2067##
2068{ 'command': 'migrate-pause', 'allow-oob': true }
2069
2070##
2071# @UNPLUG_PRIMARY:
2072#
2073# Emitted from source side of a migration when migration state is
2074# WAIT_UNPLUG. Device was unplugged by guest operating system.  Device
2075# resources in QEMU are kept on standby to be able to re-plug it in
2076# case of migration failure.
2077#
2078# @device-id: QEMU device id of the unplugged device
2079#
2080# Since: 4.2
2081#
2082# Example:
2083#
2084#     <- { "event": "UNPLUG_PRIMARY",
2085#          "data": { "device-id": "hostdev0" },
2086#          "timestamp": { "seconds": 1265044230, "microseconds": 450486 } }
2087##
2088{ 'event': 'UNPLUG_PRIMARY',
2089  'data': { 'device-id': 'str' } }
2090
2091##
2092# @DirtyRateVcpu:
2093#
2094# Dirty rate of vcpu.
2095#
2096# @id: vcpu index.
2097#
2098# @dirty-rate: dirty rate.
2099#
2100# Since: 6.2
2101##
2102{ 'struct': 'DirtyRateVcpu',
2103  'data': { 'id': 'int', 'dirty-rate': 'int64' } }
2104
2105##
2106# @DirtyRateStatus:
2107#
2108# Dirty page rate measurement status.
2109#
2110# @unstarted: measuring thread has not been started yet
2111#
2112# @measuring: measuring thread is running
2113#
2114# @measured: dirty page rate is measured and the results are available
2115#
2116# Since: 5.2
2117##
2118{ 'enum': 'DirtyRateStatus',
2119  'data': [ 'unstarted', 'measuring', 'measured'] }
2120
2121##
2122# @DirtyRateMeasureMode:
2123#
2124# Method used to measure dirty page rate.  Differences between
2125# available methods are explained in @calc-dirty-rate.
2126#
2127# @page-sampling: use page sampling
2128#
2129# @dirty-ring: use dirty ring
2130#
2131# @dirty-bitmap: use dirty bitmap
2132#
2133# Since: 6.2
2134##
2135{ 'enum': 'DirtyRateMeasureMode',
2136  'data': ['page-sampling', 'dirty-ring', 'dirty-bitmap'] }
2137
2138##
2139# @TimeUnit:
2140#
2141# Specifies unit in which time-related value is specified.
2142#
2143# @second: value is in seconds
2144#
2145# @millisecond: value is in milliseconds
2146#
2147# Since: 8.2
2148#
2149##
2150{ 'enum': 'TimeUnit',
2151  'data': ['second', 'millisecond'] }
2152
2153##
2154# @DirtyRateInfo:
2155#
2156# Information about measured dirty page rate.
2157#
2158# @dirty-rate: an estimate of the dirty page rate of the VM in units
2159#     of MiB/s.  Value is present only when @status is 'measured'.
2160#
2161# @status: current status of dirty page rate measurements
2162#
2163# @start-time: start time in units of second for calculation
2164#
2165# @calc-time: time period for which dirty page rate was measured,
2166#     expressed and rounded down to @calc-time-unit.
2167#
2168# @calc-time-unit: time unit of @calc-time  (Since 8.2)
2169#
2170# @sample-pages: number of sampled pages per GiB of guest memory.
2171#     Valid only in page-sampling mode (Since 6.1)
2172#
2173# @mode: mode that was used to measure dirty page rate (Since 6.2)
2174#
2175# @vcpu-dirty-rate: dirty rate for each vCPU if dirty-ring mode was
2176#     specified (Since 6.2)
2177#
2178# Since: 5.2
2179##
2180{ 'struct': 'DirtyRateInfo',
2181  'data': {'*dirty-rate': 'int64',
2182           'status': 'DirtyRateStatus',
2183           'start-time': 'int64',
2184           'calc-time': 'int64',
2185           'calc-time-unit': 'TimeUnit',
2186           'sample-pages': 'uint64',
2187           'mode': 'DirtyRateMeasureMode',
2188           '*vcpu-dirty-rate': [ 'DirtyRateVcpu' ] } }
2189
2190##
2191# @calc-dirty-rate:
2192#
2193# Start measuring dirty page rate of the VM.  Results can be retrieved
2194# with @query-dirty-rate after measurements are completed.
2195#
2196# Dirty page rate is the number of pages changed in a given time
2197# period expressed in MiB/s.  The following methods of calculation are
2198# available:
2199#
2200# 1. In page sampling mode, a random subset of pages are selected and
2201#    hashed twice: once at the beginning of measurement time period,
2202#    and once again at the end.  If two hashes for some page are
2203#    different, the page is counted as changed.  Since this method
2204#    relies on sampling and hashing, calculated dirty page rate is
2205#    only an estimate of its true value.  Increasing @sample-pages
2206#    improves estimation quality at the cost of higher computational
2207#    overhead.
2208#
2209# 2. Dirty bitmap mode captures writes to memory (for example by
2210#    temporarily revoking write access to all pages) and counting page
2211#    faults.  Information about modified pages is collected into a
2212#    bitmap, where each bit corresponds to one guest page.  This mode
2213#    requires that KVM accelerator property "dirty-ring-size" is *not*
2214#    set.
2215#
2216# 3. Dirty ring mode is similar to dirty bitmap mode, but the
2217#    information about modified pages is collected into ring buffer.
2218#    This mode tracks page modification per each vCPU separately.  It
2219#    requires that KVM accelerator property "dirty-ring-size" is set.
2220#
2221# @calc-time: time period for which dirty page rate is calculated.
2222#     By default it is specified in seconds, but the unit can be set
2223#     explicitly with @calc-time-unit.  Note that larger @calc-time
2224#     values will typically result in smaller dirty page rates because
2225#     page dirtying is a one-time event.  Once some page is counted
2226#     as dirty during @calc-time period, further writes to this page
2227#     will not increase dirty page rate anymore.
2228#
2229# @calc-time-unit: time unit in which @calc-time is specified.
2230#     By default it is seconds. (Since 8.2)
2231#
2232# @sample-pages: number of sampled pages per each GiB of guest memory.
2233#     Default value is 512.  For 4KiB guest pages this corresponds to
2234#     sampling ratio of 0.2%.  This argument is used only in page
2235#     sampling mode.  (Since 6.1)
2236#
2237# @mode: mechanism for tracking dirty pages.  Default value is
2238#     'page-sampling'.  Others are 'dirty-bitmap' and 'dirty-ring'.
2239#     (Since 6.1)
2240#
2241# Since: 5.2
2242#
2243# Example:
2244#
2245#     -> {"execute": "calc-dirty-rate", "arguments": {"calc-time": 1,
2246#                                                     'sample-pages': 512} }
2247#     <- { "return": {} }
2248#
2249#     Measure dirty rate using dirty bitmap for 500 milliseconds:
2250#
2251#     -> {"execute": "calc-dirty-rate", "arguments": {"calc-time": 500,
2252#         "calc-time-unit": "millisecond", "mode": "dirty-bitmap"} }
2253#
2254#     <- { "return": {} }
2255##
2256{ 'command': 'calc-dirty-rate', 'data': {'calc-time': 'int64',
2257                                         '*calc-time-unit': 'TimeUnit',
2258                                         '*sample-pages': 'int',
2259                                         '*mode': 'DirtyRateMeasureMode'} }
2260
2261##
2262# @query-dirty-rate:
2263#
2264# Query results of the most recent invocation of @calc-dirty-rate.
2265#
2266# @calc-time-unit: time unit in which to report calculation time.
2267#     By default it is reported in seconds. (Since 8.2)
2268#
2269# Since: 5.2
2270#
2271# Examples:
2272#
2273#     1. Measurement is in progress:
2274#
2275#     <- {"status": "measuring", "sample-pages": 512,
2276#         "mode": "page-sampling", "start-time": 1693900454, "calc-time": 10,
2277#         "calc-time-unit": "second"}
2278#
2279#     2. Measurement has been completed:
2280#
2281#     <- {"status": "measured", "sample-pages": 512, "dirty-rate": 108,
2282#         "mode": "page-sampling", "start-time": 1693900454, "calc-time": 10,
2283#         "calc-time-unit": "second"}
2284##
2285{ 'command': 'query-dirty-rate', 'data': {'*calc-time-unit': 'TimeUnit' },
2286                                 'returns': 'DirtyRateInfo' }
2287
2288##
2289# @DirtyLimitInfo:
2290#
2291# Dirty page rate limit information of a virtual CPU.
2292#
2293# @cpu-index: index of a virtual CPU.
2294#
2295# @limit-rate: upper limit of dirty page rate (MB/s) for a virtual
2296#     CPU, 0 means unlimited.
2297#
2298# @current-rate: current dirty page rate (MB/s) for a virtual CPU.
2299#
2300# Since: 7.1
2301##
2302{ 'struct': 'DirtyLimitInfo',
2303  'data': { 'cpu-index': 'int',
2304            'limit-rate': 'uint64',
2305            'current-rate': 'uint64' } }
2306
2307##
2308# @set-vcpu-dirty-limit:
2309#
2310# Set the upper limit of dirty page rate for virtual CPUs.
2311#
2312# Requires KVM with accelerator property "dirty-ring-size" set.  A
2313# virtual CPU's dirty page rate is a measure of its memory load.  To
2314# observe dirty page rates, use @calc-dirty-rate.
2315#
2316# @cpu-index: index of a virtual CPU, default is all.
2317#
2318# @dirty-rate: upper limit of dirty page rate (MB/s) for virtual CPUs.
2319#
2320# Since: 7.1
2321#
2322# Example:
2323#
2324#     -> {"execute": "set-vcpu-dirty-limit"}
2325#         "arguments": { "dirty-rate": 200,
2326#                        "cpu-index": 1 } }
2327#     <- { "return": {} }
2328##
2329{ 'command': 'set-vcpu-dirty-limit',
2330  'data': { '*cpu-index': 'int',
2331            'dirty-rate': 'uint64' } }
2332
2333##
2334# @cancel-vcpu-dirty-limit:
2335#
2336# Cancel the upper limit of dirty page rate for virtual CPUs.
2337#
2338# Cancel the dirty page limit for the vCPU which has been set with
2339# set-vcpu-dirty-limit command.  Note that this command requires
2340# support from dirty ring, same as the "set-vcpu-dirty-limit".
2341#
2342# @cpu-index: index of a virtual CPU, default is all.
2343#
2344# Since: 7.1
2345#
2346# Example:
2347#
2348#     -> {"execute": "cancel-vcpu-dirty-limit"},
2349#         "arguments": { "cpu-index": 1 } }
2350#     <- { "return": {} }
2351##
2352{ 'command': 'cancel-vcpu-dirty-limit',
2353  'data': { '*cpu-index': 'int'} }
2354
2355##
2356# @query-vcpu-dirty-limit:
2357#
2358# Returns information about virtual CPU dirty page rate limits, if
2359# any.
2360#
2361# Since: 7.1
2362#
2363# Example:
2364#
2365#     -> {"execute": "query-vcpu-dirty-limit"}
2366#     <- {"return": [
2367#            { "limit-rate": 60, "current-rate": 3, "cpu-index": 0},
2368#            { "limit-rate": 60, "current-rate": 3, "cpu-index": 1}]}
2369##
2370{ 'command': 'query-vcpu-dirty-limit',
2371  'returns': [ 'DirtyLimitInfo' ] }
2372
2373##
2374# @MigrationThreadInfo:
2375#
2376# Information about migrationthreads
2377#
2378# @name: the name of migration thread
2379#
2380# @thread-id: ID of the underlying host thread
2381#
2382# Since: 7.2
2383##
2384{ 'struct': 'MigrationThreadInfo',
2385  'data': {'name': 'str',
2386           'thread-id': 'int'} }
2387
2388##
2389# @query-migrationthreads:
2390#
2391# Returns information of migration threads
2392#
2393# data: migration thread name
2394#
2395# Returns: information about migration threads
2396#
2397# Since: 7.2
2398##
2399{ 'command': 'query-migrationthreads',
2400  'returns': ['MigrationThreadInfo'] }
2401
2402##
2403# @snapshot-save:
2404#
2405# Save a VM snapshot
2406#
2407# @job-id: identifier for the newly created job
2408#
2409# @tag: name of the snapshot to create
2410#
2411# @vmstate: block device node name to save vmstate to
2412#
2413# @devices: list of block device node names to save a snapshot to
2414#
2415# Applications should not assume that the snapshot save is complete
2416# when this command returns.  The job commands / events must be used
2417# to determine completion and to fetch details of any errors that
2418# arise.
2419#
2420# Note that execution of the guest CPUs may be stopped during the time
2421# it takes to save the snapshot.  A future version of QEMU may ensure
2422# CPUs are executing continuously.
2423#
2424# It is strongly recommended that @devices contain all writable block
2425# device nodes if a consistent snapshot is required.
2426#
2427# If @tag already exists, an error will be reported
2428#
2429# Returns: nothing
2430#
2431# Example:
2432#
2433#     -> { "execute": "snapshot-save",
2434#          "arguments": {
2435#             "job-id": "snapsave0",
2436#             "tag": "my-snap",
2437#             "vmstate": "disk0",
2438#             "devices": ["disk0", "disk1"]
2439#          }
2440#        }
2441#     <- { "return": { } }
2442#     <- {"event": "JOB_STATUS_CHANGE",
2443#         "timestamp": {"seconds": 1432121972, "microseconds": 744001},
2444#         "data": {"status": "created", "id": "snapsave0"}}
2445#     <- {"event": "JOB_STATUS_CHANGE",
2446#         "timestamp": {"seconds": 1432122172, "microseconds": 744001},
2447#         "data": {"status": "running", "id": "snapsave0"}}
2448#     <- {"event": "STOP",
2449#         "timestamp": {"seconds": 1432122372, "microseconds": 744001} }
2450#     <- {"event": "RESUME",
2451#         "timestamp": {"seconds": 1432122572, "microseconds": 744001} }
2452#     <- {"event": "JOB_STATUS_CHANGE",
2453#         "timestamp": {"seconds": 1432122772, "microseconds": 744001},
2454#         "data": {"status": "waiting", "id": "snapsave0"}}
2455#     <- {"event": "JOB_STATUS_CHANGE",
2456#         "timestamp": {"seconds": 1432122972, "microseconds": 744001},
2457#         "data": {"status": "pending", "id": "snapsave0"}}
2458#     <- {"event": "JOB_STATUS_CHANGE",
2459#         "timestamp": {"seconds": 1432123172, "microseconds": 744001},
2460#         "data": {"status": "concluded", "id": "snapsave0"}}
2461#     -> {"execute": "query-jobs"}
2462#     <- {"return": [{"current-progress": 1,
2463#                     "status": "concluded",
2464#                     "total-progress": 1,
2465#                     "type": "snapshot-save",
2466#                     "id": "snapsave0"}]}
2467#
2468# Since: 6.0
2469##
2470{ 'command': 'snapshot-save',
2471  'data': { 'job-id': 'str',
2472            'tag': 'str',
2473            'vmstate': 'str',
2474            'devices': ['str'] } }
2475
2476##
2477# @snapshot-load:
2478#
2479# Load a VM snapshot
2480#
2481# @job-id: identifier for the newly created job
2482#
2483# @tag: name of the snapshot to load.
2484#
2485# @vmstate: block device node name to load vmstate from
2486#
2487# @devices: list of block device node names to load a snapshot from
2488#
2489# Applications should not assume that the snapshot load is complete
2490# when this command returns.  The job commands / events must be used
2491# to determine completion and to fetch details of any errors that
2492# arise.
2493#
2494# Note that execution of the guest CPUs will be stopped during the
2495# time it takes to load the snapshot.
2496#
2497# It is strongly recommended that @devices contain all writable block
2498# device nodes that can have changed since the original @snapshot-save
2499# command execution.
2500#
2501# Returns: nothing
2502#
2503# Example:
2504#
2505#     -> { "execute": "snapshot-load",
2506#          "arguments": {
2507#             "job-id": "snapload0",
2508#             "tag": "my-snap",
2509#             "vmstate": "disk0",
2510#             "devices": ["disk0", "disk1"]
2511#          }
2512#        }
2513#     <- { "return": { } }
2514#     <- {"event": "JOB_STATUS_CHANGE",
2515#         "timestamp": {"seconds": 1472124172, "microseconds": 744001},
2516#         "data": {"status": "created", "id": "snapload0"}}
2517#     <- {"event": "JOB_STATUS_CHANGE",
2518#         "timestamp": {"seconds": 1472125172, "microseconds": 744001},
2519#         "data": {"status": "running", "id": "snapload0"}}
2520#     <- {"event": "STOP",
2521#         "timestamp": {"seconds": 1472125472, "microseconds": 744001} }
2522#     <- {"event": "RESUME",
2523#         "timestamp": {"seconds": 1472125872, "microseconds": 744001} }
2524#     <- {"event": "JOB_STATUS_CHANGE",
2525#         "timestamp": {"seconds": 1472126172, "microseconds": 744001},
2526#         "data": {"status": "waiting", "id": "snapload0"}}
2527#     <- {"event": "JOB_STATUS_CHANGE",
2528#         "timestamp": {"seconds": 1472127172, "microseconds": 744001},
2529#         "data": {"status": "pending", "id": "snapload0"}}
2530#     <- {"event": "JOB_STATUS_CHANGE",
2531#         "timestamp": {"seconds": 1472128172, "microseconds": 744001},
2532#         "data": {"status": "concluded", "id": "snapload0"}}
2533#     -> {"execute": "query-jobs"}
2534#     <- {"return": [{"current-progress": 1,
2535#                     "status": "concluded",
2536#                     "total-progress": 1,
2537#                     "type": "snapshot-load",
2538#                     "id": "snapload0"}]}
2539#
2540# Since: 6.0
2541##
2542{ 'command': 'snapshot-load',
2543  'data': { 'job-id': 'str',
2544            'tag': 'str',
2545            'vmstate': 'str',
2546            'devices': ['str'] } }
2547
2548##
2549# @snapshot-delete:
2550#
2551# Delete a VM snapshot
2552#
2553# @job-id: identifier for the newly created job
2554#
2555# @tag: name of the snapshot to delete.
2556#
2557# @devices: list of block device node names to delete a snapshot from
2558#
2559# Applications should not assume that the snapshot delete is complete
2560# when this command returns.  The job commands / events must be used
2561# to determine completion and to fetch details of any errors that
2562# arise.
2563#
2564# Returns: nothing
2565#
2566# Example:
2567#
2568#     -> { "execute": "snapshot-delete",
2569#          "arguments": {
2570#             "job-id": "snapdelete0",
2571#             "tag": "my-snap",
2572#             "devices": ["disk0", "disk1"]
2573#          }
2574#        }
2575#     <- { "return": { } }
2576#     <- {"event": "JOB_STATUS_CHANGE",
2577#         "timestamp": {"seconds": 1442124172, "microseconds": 744001},
2578#         "data": {"status": "created", "id": "snapdelete0"}}
2579#     <- {"event": "JOB_STATUS_CHANGE",
2580#         "timestamp": {"seconds": 1442125172, "microseconds": 744001},
2581#         "data": {"status": "running", "id": "snapdelete0"}}
2582#     <- {"event": "JOB_STATUS_CHANGE",
2583#         "timestamp": {"seconds": 1442126172, "microseconds": 744001},
2584#         "data": {"status": "waiting", "id": "snapdelete0"}}
2585#     <- {"event": "JOB_STATUS_CHANGE",
2586#         "timestamp": {"seconds": 1442127172, "microseconds": 744001},
2587#         "data": {"status": "pending", "id": "snapdelete0"}}
2588#     <- {"event": "JOB_STATUS_CHANGE",
2589#         "timestamp": {"seconds": 1442128172, "microseconds": 744001},
2590#         "data": {"status": "concluded", "id": "snapdelete0"}}
2591#     -> {"execute": "query-jobs"}
2592#     <- {"return": [{"current-progress": 1,
2593#                     "status": "concluded",
2594#                     "total-progress": 1,
2595#                     "type": "snapshot-delete",
2596#                     "id": "snapdelete0"}]}
2597#
2598# Since: 6.0
2599##
2600{ 'command': 'snapshot-delete',
2601  'data': { 'job-id': 'str',
2602            'tag': 'str',
2603            'devices': ['str'] } }
2604