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