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