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