xref: /qemu/qapi/migration.json (revision ab4c0996)
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 target VM
20#
21# @total: total amount of bytes involved in the migration process
22#
23# @duplicate: number of duplicate (zero) pages (since 1.2)
24#
25# @skipped: number of skipped zero pages (since 1.5)
26#
27# @normal: number of normal pages (since 1.2)
28#
29# @normal-bytes: number of normal bytes sent (since 1.2)
30#
31# @dirty-pages-rate: number of pages dirtied by second by the
32#                    guest (since 1.3)
33#
34# @mbps: throughput in megabits/sec. (since 1.6)
35#
36# @dirty-sync-count: number of times that dirty ram was synchronized (since 2.1)
37#
38# @postcopy-requests: The number of page requests received from the destination
39#                     (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# Since: 0.14.0
50##
51{ 'struct': 'MigrationStats',
52  'data': {'transferred': 'int', 'remaining': 'int', 'total': 'int' ,
53           'duplicate': 'int', 'skipped': 'int', 'normal': 'int',
54           'normal-bytes': 'int', 'dirty-pages-rate' : 'int',
55           'mbps' : 'number', 'dirty-sync-count' : 'int',
56           'postcopy-requests' : 'int', 'page-size' : 'int',
57           'multifd-bytes' : 'uint64', 'pages-per-second' : 'uint64' } }
58
59##
60# @XBZRLECacheStats:
61#
62# Detailed XBZRLE migration cache statistics
63#
64# @cache-size: XBZRLE cache size
65#
66# @bytes: amount of bytes already transferred to the target VM
67#
68# @pages: amount of pages transferred to the target VM
69#
70# @cache-miss: number of cache miss
71#
72# @cache-miss-rate: rate of cache miss (since 2.1)
73#
74# @encoding-rate: rate of encoded bytes (since 5.1)
75#
76# @overflow: number of overflows
77#
78# Since: 1.2
79##
80{ 'struct': 'XBZRLECacheStats',
81  'data': {'cache-size': 'int', 'bytes': 'int', 'pages': 'int',
82           'cache-miss': 'int', 'cache-miss-rate': 'number',
83           'encoding-rate': 'number', 'overflow': 'int' } }
84
85##
86# @CompressionStats:
87#
88# Detailed migration compression statistics
89#
90# @pages: amount of pages compressed and transferred to the target VM
91#
92# @busy: count of times that no free thread was available to compress data
93#
94# @busy-rate: rate of thread busy
95#
96# @compressed-size: amount of bytes after compression
97#
98# @compression-rate: rate of compressed size
99#
100# Since: 3.1
101##
102{ 'struct': 'CompressionStats',
103  'data': {'pages': 'int', 'busy': 'int', 'busy-rate': 'number',
104           'compressed-size': 'int', 'compression-rate': 'number' } }
105
106##
107# @MigrationStatus:
108#
109# An enumeration of migration status.
110#
111# @none: no migration has ever happened.
112#
113# @setup: migration process has been initiated.
114#
115# @cancelling: in the process of cancelling migration.
116#
117# @cancelled: cancelling migration is finished.
118#
119# @active: in the process of doing migration.
120#
121# @postcopy-active: like active, but now in postcopy mode. (since 2.5)
122#
123# @postcopy-paused: during postcopy but paused. (since 3.0)
124#
125# @postcopy-recover: trying to recover from a paused postcopy. (since 3.0)
126#
127# @completed: migration is finished.
128#
129# @failed: some error occurred during migration process.
130#
131# @colo: VM is in the process of fault tolerance, VM can not get into this
132#        state unless colo capability is enabled for migration. (since 2.8)
133#
134# @pre-switchover: Paused before device serialisation. (since 2.11)
135#
136# @device: During device serialisation when pause-before-switchover is enabled
137#          (since 2.11)
138#
139# @wait-unplug: wait for device unplug request by guest OS to be completed.
140#               (since 4.2)
141#
142# Since: 2.3
143#
144##
145{ 'enum': 'MigrationStatus',
146  'data': [ 'none', 'setup', 'cancelling', 'cancelled',
147            'active', 'postcopy-active', 'postcopy-paused',
148            'postcopy-recover', 'completed', 'failed', 'colo',
149            'pre-switchover', 'device', 'wait-unplug' ] }
150
151##
152# @MigrationInfo:
153#
154# Information about current migration process.
155#
156# @status: @MigrationStatus describing the current migration status.
157#          If this field is not returned, no migration process
158#          has been initiated
159#
160# @ram: @MigrationStats containing detailed migration
161#       status, only returned if status is 'active' or
162#       'completed'(since 1.2)
163#
164# @disk: @MigrationStats containing detailed disk migration
165#        status, only returned if status is 'active' and it is a block
166#        migration
167#
168# @xbzrle-cache: @XBZRLECacheStats containing detailed XBZRLE
169#                migration statistics, only returned if XBZRLE feature is on and
170#                status is 'active' or 'completed' (since 1.2)
171#
172# @total-time: total amount of milliseconds since migration started.
173#              If migration has ended, it returns the total migration
174#              time. (since 1.2)
175#
176# @downtime: only present when migration finishes correctly
177#            total downtime in milliseconds for the guest.
178#            (since 1.3)
179#
180# @expected-downtime: only present while migration is active
181#                     expected downtime in milliseconds for the guest in last walk
182#                     of the dirty bitmap. (since 1.3)
183#
184# @setup-time: amount of setup time in milliseconds *before* the
185#              iterations begin but *after* the QMP command is issued. This is designed
186#              to provide an accounting of any activities (such as RDMA pinning) which
187#              may be expensive, but do not actually occur during the iterative
188#              migration rounds themselves. (since 1.6)
189#
190# @cpu-throttle-percentage: percentage of time guest cpus are being
191#                           throttled during auto-converge. This is only present when auto-converge
192#                           has started throttling guest cpus. (Since 2.7)
193#
194# @error-desc: the human readable error description string, when
195#              @status is 'failed'. Clients should not attempt to parse the
196#              error strings. (Since 2.7)
197#
198# @postcopy-blocktime: total time when all vCPU were blocked during postcopy
199#                      live migration. This is only present when the postcopy-blocktime
200#                      migration capability is enabled. (Since 3.0)
201#
202# @postcopy-vcpu-blocktime: list of the postcopy blocktime per vCPU.  This is
203#                           only present when the postcopy-blocktime migration capability
204#                           is enabled. (Since 3.0)
205#
206# @compression: migration compression statistics, only returned if compression
207#               feature is on and status is 'active' or 'completed' (Since 3.1)
208#
209# @socket-address: Only used for tcp, to know what the real port is (Since 4.0)
210#
211# Since: 0.14.0
212##
213{ 'struct': 'MigrationInfo',
214  'data': {'*status': 'MigrationStatus', '*ram': 'MigrationStats',
215           '*disk': 'MigrationStats',
216           '*xbzrle-cache': 'XBZRLECacheStats',
217           '*total-time': 'int',
218           '*expected-downtime': 'int',
219           '*downtime': 'int',
220           '*setup-time': 'int',
221           '*cpu-throttle-percentage': 'int',
222           '*error-desc': 'str',
223           '*postcopy-blocktime' : 'uint32',
224           '*postcopy-vcpu-blocktime': ['uint32'],
225           '*compression': 'CompressionStats',
226           '*socket-address': ['SocketAddress'] } }
227
228##
229# @query-migrate:
230#
231# Returns information about current migration process. If migration
232# is active there will be another json-object with RAM migration
233# status and if block migration is active another one with block
234# migration status.
235#
236# Returns: @MigrationInfo
237#
238# Since: 0.14.0
239#
240# Example:
241#
242# 1. Before the first migration
243#
244# -> { "execute": "query-migrate" }
245# <- { "return": {} }
246#
247# 2. Migration is done and has succeeded
248#
249# -> { "execute": "query-migrate" }
250# <- { "return": {
251#         "status": "completed",
252#         "total-time":12345,
253#         "setup-time":12345,
254#         "downtime":12345,
255#         "ram":{
256#           "transferred":123,
257#           "remaining":123,
258#           "total":246,
259#           "duplicate":123,
260#           "normal":123,
261#           "normal-bytes":123456,
262#           "dirty-sync-count":15
263#         }
264#      }
265#    }
266#
267# 3. Migration is done and has failed
268#
269# -> { "execute": "query-migrate" }
270# <- { "return": { "status": "failed" } }
271#
272# 4. Migration is being performed and is not a block migration:
273#
274# -> { "execute": "query-migrate" }
275# <- {
276#       "return":{
277#          "status":"active",
278#          "total-time":12345,
279#          "setup-time":12345,
280#          "expected-downtime":12345,
281#          "ram":{
282#             "transferred":123,
283#             "remaining":123,
284#             "total":246,
285#             "duplicate":123,
286#             "normal":123,
287#             "normal-bytes":123456,
288#             "dirty-sync-count":15
289#          }
290#       }
291#    }
292#
293# 5. Migration is being performed and is a block migration:
294#
295# -> { "execute": "query-migrate" }
296# <- {
297#       "return":{
298#          "status":"active",
299#          "total-time":12345,
300#          "setup-time":12345,
301#          "expected-downtime":12345,
302#          "ram":{
303#             "total":1057024,
304#             "remaining":1053304,
305#             "transferred":3720,
306#             "duplicate":123,
307#             "normal":123,
308#             "normal-bytes":123456,
309#             "dirty-sync-count":15
310#          },
311#          "disk":{
312#             "total":20971520,
313#             "remaining":20880384,
314#             "transferred":91136
315#          }
316#       }
317#    }
318#
319# 6. Migration is being performed and XBZRLE is active:
320#
321# -> { "execute": "query-migrate" }
322# <- {
323#       "return":{
324#          "status":"active",
325#          "total-time":12345,
326#          "setup-time":12345,
327#          "expected-downtime":12345,
328#          "ram":{
329#             "total":1057024,
330#             "remaining":1053304,
331#             "transferred":3720,
332#             "duplicate":10,
333#             "normal":3333,
334#             "normal-bytes":3412992,
335#             "dirty-sync-count":15
336#          },
337#          "xbzrle-cache":{
338#             "cache-size":67108864,
339#             "bytes":20971520,
340#             "pages":2444343,
341#             "cache-miss":2244,
342#             "cache-miss-rate":0.123,
343#             "encoding-rate":80.1,
344#             "overflow":34434
345#          }
346#       }
347#    }
348#
349##
350{ 'command': 'query-migrate', 'returns': 'MigrationInfo' }
351
352##
353# @MigrationCapability:
354#
355# Migration capabilities enumeration
356#
357# @xbzrle: Migration supports xbzrle (Xor Based Zero Run Length Encoding).
358#          This feature allows us to minimize migration traffic for certain work
359#          loads, by sending compressed difference of the pages
360#
361# @rdma-pin-all: Controls whether or not the entire VM memory footprint is
362#                mlock()'d on demand or all at once. Refer to docs/rdma.txt for usage.
363#                Disabled by default. (since 2.0)
364#
365# @zero-blocks: During storage migration encode blocks of zeroes efficiently. This
366#               essentially saves 1MB of zeroes per block on the wire. Enabling requires
367#               source and target VM to support this feature. To enable it is sufficient
368#               to enable the capability on the source VM. The feature is disabled by
369#               default. (since 1.6)
370#
371# @compress: Use multiple compression threads to accelerate live migration.
372#            This feature can help to reduce the migration traffic, by sending
373#            compressed pages. Please note that if compress and xbzrle are both
374#            on, compress only takes effect in the ram bulk stage, after that,
375#            it will be disabled and only xbzrle takes effect, this can help to
376#            minimize migration traffic. The feature is disabled by default.
377#            (since 2.4 )
378#
379# @events: generate events for each migration state change
380#          (since 2.4 )
381#
382# @auto-converge: If enabled, QEMU will automatically throttle down the guest
383#                 to speed up convergence of RAM migration. (since 1.6)
384#
385# @postcopy-ram: Start executing on the migration target before all of RAM has
386#                been migrated, pulling the remaining pages along as needed. The
387#                capacity must have the same setting on both source and target
388#                or migration will not even start. NOTE: If the migration fails during
389#                postcopy the VM will fail.  (since 2.6)
390#
391# @x-colo: If enabled, migration will never end, and the state of the VM on the
392#          primary side will be migrated continuously to the VM on secondary
393#          side, this process is called COarse-Grain LOck Stepping (COLO) for
394#          Non-stop Service. (since 2.8)
395#
396# @release-ram: if enabled, qemu will free the migrated ram pages on the source
397#               during postcopy-ram migration. (since 2.9)
398#
399# @block: If enabled, QEMU will also migrate the contents of all block
400#         devices.  Default is disabled.  A possible alternative uses
401#         mirror jobs to a builtin NBD server on the destination, which
402#         offers more flexibility.
403#         (Since 2.10)
404#
405# @return-path: If enabled, migration will use the return path even
406#               for precopy. (since 2.10)
407#
408# @pause-before-switchover: Pause outgoing migration before serialising device
409#                           state and before disabling block IO (since 2.11)
410#
411# @multifd: Use more than one fd for migration (since 4.0)
412#
413# @dirty-bitmaps: If enabled, QEMU will migrate named dirty bitmaps.
414#                 (since 2.12)
415#
416# @postcopy-blocktime: Calculate downtime for postcopy live migration
417#                      (since 3.0)
418#
419# @late-block-activate: If enabled, the destination will not activate block
420#                       devices (and thus take locks) immediately at the end of migration.
421#                       (since 3.0)
422#
423# @x-ignore-shared: If enabled, QEMU will not migrate shared memory (since 4.0)
424#
425# @validate-uuid: Send the UUID of the source to allow the destination
426#                 to ensure it is the same. (since 4.2)
427#
428# Since: 1.2
429##
430{ 'enum': 'MigrationCapability',
431  'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks',
432           'compress', 'events', 'postcopy-ram', 'x-colo', 'release-ram',
433           'block', 'return-path', 'pause-before-switchover', 'multifd',
434           'dirty-bitmaps', 'postcopy-blocktime', 'late-block-activate',
435           'x-ignore-shared', 'validate-uuid' ] }
436
437##
438# @MigrationCapabilityStatus:
439#
440# Migration capability information
441#
442# @capability: capability enum
443#
444# @state: capability state bool
445#
446# Since: 1.2
447##
448{ 'struct': 'MigrationCapabilityStatus',
449  'data': { 'capability' : 'MigrationCapability', 'state' : 'bool' } }
450
451##
452# @migrate-set-capabilities:
453#
454# Enable/Disable the following migration capabilities (like xbzrle)
455#
456# @capabilities: json array of capability modifications to make
457#
458# Since: 1.2
459#
460# Example:
461#
462# -> { "execute": "migrate-set-capabilities" , "arguments":
463#      { "capabilities": [ { "capability": "xbzrle", "state": true } ] } }
464#
465##
466{ 'command': 'migrate-set-capabilities',
467  'data': { 'capabilities': ['MigrationCapabilityStatus'] } }
468
469##
470# @query-migrate-capabilities:
471#
472# Returns information about the current migration capabilities status
473#
474# Returns: @MigrationCapabilitiesStatus
475#
476# Since: 1.2
477#
478# Example:
479#
480# -> { "execute": "query-migrate-capabilities" }
481# <- { "return": [
482#       {"state": false, "capability": "xbzrle"},
483#       {"state": false, "capability": "rdma-pin-all"},
484#       {"state": false, "capability": "auto-converge"},
485#       {"state": false, "capability": "zero-blocks"},
486#       {"state": false, "capability": "compress"},
487#       {"state": true, "capability": "events"},
488#       {"state": false, "capability": "postcopy-ram"},
489#       {"state": false, "capability": "x-colo"}
490#    ]}
491#
492##
493{ 'command': 'query-migrate-capabilities', 'returns':   ['MigrationCapabilityStatus']}
494
495##
496# @MultiFDCompression:
497#
498# An enumeration of multifd compression methods.
499#
500# @none: no compression.
501# @zlib: use zlib compression method.
502# @zstd: use zstd compression method.
503#
504# Since: 5.0
505#
506##
507{ 'enum': 'MultiFDCompression',
508  'data': [ 'none', 'zlib',
509            { 'name': 'zstd', 'if': 'defined(CONFIG_ZSTD)' } ] }
510
511##
512# @BitmapMigrationBitmapAlias:
513#
514# @name: The name of the bitmap.
515#
516# @alias: An alias name for migration (for example the bitmap name on
517#         the opposite site).
518#
519# Since: 5.2
520##
521{ 'struct': 'BitmapMigrationBitmapAlias',
522  'data': {
523      'name': 'str',
524      'alias': 'str'
525  } }
526
527##
528# @BitmapMigrationNodeAlias:
529#
530# Maps a block node name and the bitmaps it has to aliases for dirty
531# bitmap migration.
532#
533# @node-name: A block node name.
534#
535# @alias: An alias block node name for migration (for example the
536#         node name on the opposite site).
537#
538# @bitmaps: Mappings for the bitmaps on this node.
539#
540# Since: 5.2
541##
542{ 'struct': 'BitmapMigrationNodeAlias',
543  'data': {
544      'node-name': 'str',
545      'alias': 'str',
546      'bitmaps': [ 'BitmapMigrationBitmapAlias' ]
547  } }
548
549##
550# @MigrationParameter:
551#
552# Migration parameters enumeration
553#
554# @announce-initial: Initial delay (in milliseconds) before sending the first
555#                    announce (Since 4.0)
556#
557# @announce-max: Maximum delay (in milliseconds) between packets in the
558#                announcement (Since 4.0)
559#
560# @announce-rounds: Number of self-announce packets sent after migration
561#                   (Since 4.0)
562#
563# @announce-step: Increase in delay (in milliseconds) between subsequent
564#                 packets in the announcement (Since 4.0)
565#
566# @compress-level: Set the compression level to be used in live migration,
567#                  the compression level is an integer between 0 and 9, where 0 means
568#                  no compression, 1 means the best compression speed, and 9 means best
569#                  compression ratio which will consume more CPU.
570#
571# @compress-threads: Set compression thread count to be used in live migration,
572#                    the compression thread count is an integer between 1 and 255.
573#
574# @compress-wait-thread: Controls behavior when all compression threads are
575#                        currently busy. If true (default), wait for a free
576#                        compression thread to become available; otherwise,
577#                        send the page uncompressed. (Since 3.1)
578#
579# @decompress-threads: Set decompression thread count to be used in live
580#                      migration, the decompression thread count is an integer between 1
581#                      and 255. Usually, decompression is at least 4 times as fast as
582#                      compression, so set the decompress-threads to the number about 1/4
583#                      of compress-threads is adequate.
584#
585# @throttle-trigger-threshold: The ratio of bytes_dirty_period and bytes_xfer_period
586#                              to trigger throttling. It is expressed as percentage.
587#                              The default value is 50. (Since 5.0)
588#
589# @cpu-throttle-initial: Initial percentage of time guest cpus are throttled
590#                        when migration auto-converge is activated. The
591#                        default value is 20. (Since 2.7)
592#
593# @cpu-throttle-increment: throttle percentage increase each time
594#                          auto-converge detects that migration is not making
595#                          progress. The default value is 10. (Since 2.7)
596#
597# @cpu-throttle-tailslow: Make CPU throttling slower at tail stage
598#                         At the tail stage of throttling, the Guest is very
599#                         sensitive to CPU percentage while the @cpu-throttle
600#                         -increment is excessive usually at tail stage.
601#                         If this parameter is true, we will compute the ideal
602#                         CPU percentage used by the Guest, which may exactly make
603#                         the dirty rate match the dirty rate threshold. Then we
604#                         will choose a smaller throttle increment between the
605#                         one specified by @cpu-throttle-increment and the one
606#                         generated by ideal CPU percentage.
607#                         Therefore, it is compatible to traditional throttling,
608#                         meanwhile the throttle increment won't be excessive
609#                         at tail stage.
610#                         The default value is false. (Since 5.1)
611#
612# @tls-creds: ID of the 'tls-creds' object that provides credentials for
613#             establishing a TLS connection over the migration data channel.
614#             On the outgoing side of the migration, the credentials must
615#             be for a 'client' endpoint, while for the incoming side the
616#             credentials must be for a 'server' endpoint. Setting this
617#             will enable TLS for all migrations. The default is unset,
618#             resulting in unsecured migration at the QEMU level. (Since 2.7)
619#
620# @tls-hostname: hostname of the target host for the migration. This is
621#                required when using x509 based TLS credentials and the
622#                migration URI does not already include a hostname. For
623#                example if using fd: or exec: based migration, the
624#                hostname must be provided so that the server's x509
625#                certificate identity can be validated. (Since 2.7)
626#
627# @tls-authz: ID of the 'authz' object subclass that provides access control
628#             checking of the TLS x509 certificate distinguished name.
629#             This object is only resolved at time of use, so can be deleted
630#             and recreated on the fly while the migration server is active.
631#             If missing, it will default to denying access (Since 4.0)
632#
633# @max-bandwidth: to set maximum speed for migration. maximum speed in
634#                 bytes per second. (Since 2.8)
635#
636# @downtime-limit: set maximum tolerated downtime for migration. maximum
637#                  downtime in milliseconds (Since 2.8)
638#
639# @x-checkpoint-delay: The delay time (in ms) between two COLO checkpoints in
640#                      periodic mode. (Since 2.8)
641#
642# @block-incremental: Affects how much storage is migrated when the
643#                     block migration capability is enabled.  When false, the entire
644#                     storage backing chain is migrated into a flattened image at
645#                     the destination; when true, only the active qcow2 layer is
646#                     migrated and the destination must already have access to the
647#                     same backing chain as was used on the source.  (since 2.10)
648#
649# @multifd-channels: Number of channels used to migrate data in
650#                    parallel. This is the same number that the
651#                    number of sockets used for migration.  The
652#                    default value is 2 (since 4.0)
653#
654# @xbzrle-cache-size: cache size to be used by XBZRLE migration.  It
655#                     needs to be a multiple of the target page size
656#                     and a power of 2
657#                     (Since 2.11)
658#
659# @max-postcopy-bandwidth: Background transfer bandwidth during postcopy.
660#                          Defaults to 0 (unlimited).  In bytes per second.
661#                          (Since 3.0)
662#
663# @max-cpu-throttle: maximum cpu throttle percentage.
664#                    Defaults to 99. (Since 3.1)
665#
666# @multifd-compression: Which compression method to use.
667#                       Defaults to none. (Since 5.0)
668#
669# @multifd-zlib-level: Set the compression level to be used in live
670#          migration, the compression level is an integer between 0
671#          and 9, where 0 means no compression, 1 means the best
672#          compression speed, and 9 means best compression ratio which
673#          will consume more CPU.
674#          Defaults to 1. (Since 5.0)
675#
676# @multifd-zstd-level: Set the compression level to be used in live
677#          migration, the compression level is an integer between 0
678#          and 20, where 0 means no compression, 1 means the best
679#          compression speed, and 20 means best compression ratio which
680#          will consume more CPU.
681#          Defaults to 1. (Since 5.0)
682#
683# @block-bitmap-mapping: Maps block nodes and bitmaps on them to
684#          aliases for the purpose of dirty bitmap migration.  Such
685#          aliases may for example be the corresponding names on the
686#          opposite site.
687#          The mapping must be one-to-one, but not necessarily
688#          complete: On the source, unmapped bitmaps and all bitmaps
689#          on unmapped nodes will be ignored.  On the destination,
690#          encountering an unmapped alias in the incoming migration
691#          stream will result in a report, and all further bitmap
692#          migration data will then be discarded.
693#          Note that the destination does not know about bitmaps it
694#          does not receive, so there is no limitation or requirement
695#          regarding the number of bitmaps received, or how they are
696#          named, or on which nodes they are placed.
697#          By default (when this parameter has never been set), bitmap
698#          names are mapped to themselves.  Nodes are mapped to their
699#          block device name if there is one, and to their node name
700#          otherwise. (Since 5.2)
701#
702# Since: 2.4
703##
704{ 'enum': 'MigrationParameter',
705  'data': ['announce-initial', 'announce-max',
706           'announce-rounds', 'announce-step',
707           'compress-level', 'compress-threads', 'decompress-threads',
708           'compress-wait-thread', 'throttle-trigger-threshold',
709           'cpu-throttle-initial', 'cpu-throttle-increment',
710           'cpu-throttle-tailslow',
711           'tls-creds', 'tls-hostname', 'tls-authz', 'max-bandwidth',
712           'downtime-limit', 'x-checkpoint-delay', 'block-incremental',
713           'multifd-channels',
714           'xbzrle-cache-size', 'max-postcopy-bandwidth',
715           'max-cpu-throttle', 'multifd-compression',
716           'multifd-zlib-level' ,'multifd-zstd-level',
717           'block-bitmap-mapping' ] }
718
719##
720# @MigrateSetParameters:
721#
722# @announce-initial: Initial delay (in milliseconds) before sending the first
723#                    announce (Since 4.0)
724#
725# @announce-max: Maximum delay (in milliseconds) between packets in the
726#                announcement (Since 4.0)
727#
728# @announce-rounds: Number of self-announce packets sent after migration
729#                   (Since 4.0)
730#
731# @announce-step: Increase in delay (in milliseconds) between subsequent
732#                 packets in the announcement (Since 4.0)
733#
734# @compress-level: compression level
735#
736# @compress-threads: compression thread count
737#
738# @compress-wait-thread: Controls behavior when all compression threads are
739#                        currently busy. If true (default), wait for a free
740#                        compression thread to become available; otherwise,
741#                        send the page uncompressed. (Since 3.1)
742#
743# @decompress-threads: decompression thread count
744#
745# @throttle-trigger-threshold: The ratio of bytes_dirty_period and bytes_xfer_period
746#                              to trigger throttling. It is expressed as percentage.
747#                              The default value is 50. (Since 5.0)
748#
749# @cpu-throttle-initial: Initial percentage of time guest cpus are
750#                        throttled when migration auto-converge is activated.
751#                        The default value is 20. (Since 2.7)
752#
753# @cpu-throttle-increment: throttle percentage increase each time
754#                          auto-converge detects that migration is not making
755#                          progress. The default value is 10. (Since 2.7)
756#
757# @cpu-throttle-tailslow: Make CPU throttling slower at tail stage
758#                         At the tail stage of throttling, the Guest is very
759#                         sensitive to CPU percentage while the @cpu-throttle
760#                         -increment is excessive usually at tail stage.
761#                         If this parameter is true, we will compute the ideal
762#                         CPU percentage used by the Guest, which may exactly make
763#                         the dirty rate match the dirty rate threshold. Then we
764#                         will choose a smaller throttle increment between the
765#                         one specified by @cpu-throttle-increment and the one
766#                         generated by ideal CPU percentage.
767#                         Therefore, it is compatible to traditional throttling,
768#                         meanwhile the throttle increment won't be excessive
769#                         at tail stage.
770#                         The default value is false. (Since 5.1)
771#
772# @tls-creds: ID of the 'tls-creds' object that provides credentials
773#             for establishing a TLS connection over the migration data
774#             channel. On the outgoing side of the migration, the credentials
775#             must be for a 'client' endpoint, while for the incoming side the
776#             credentials must be for a 'server' endpoint. Setting this
777#             to a non-empty string enables TLS for all migrations.
778#             An empty string means that QEMU will use plain text mode for
779#             migration, rather than TLS (Since 2.9)
780#             Previously (since 2.7), this was reported by omitting
781#             tls-creds instead.
782#
783# @tls-hostname: hostname of the target host for the migration. This
784#                is required when using x509 based TLS credentials and the
785#                migration URI does not already include a hostname. For
786#                example if using fd: or exec: based migration, the
787#                hostname must be provided so that the server's x509
788#                certificate identity can be validated. (Since 2.7)
789#                An empty string means that QEMU will use the hostname
790#                associated with the migration URI, if any. (Since 2.9)
791#                Previously (since 2.7), this was reported by omitting
792#                tls-hostname instead.
793#
794# @max-bandwidth: to set maximum speed for migration. maximum speed in
795#                 bytes per second. (Since 2.8)
796#
797# @downtime-limit: set maximum tolerated downtime for migration. maximum
798#                  downtime in milliseconds (Since 2.8)
799#
800# @x-checkpoint-delay: the delay time between two COLO checkpoints. (Since 2.8)
801#
802# @block-incremental: Affects how much storage is migrated when the
803#                     block migration capability is enabled.  When false, the entire
804#                     storage backing chain is migrated into a flattened image at
805#                     the destination; when true, only the active qcow2 layer is
806#                     migrated and the destination must already have access to the
807#                     same backing chain as was used on the source.  (since 2.10)
808#
809# @multifd-channels: Number of channels used to migrate data in
810#                    parallel. This is the same number that the
811#                    number of sockets used for migration.  The
812#                    default value is 2 (since 4.0)
813#
814# @xbzrle-cache-size: cache size to be used by XBZRLE migration.  It
815#                     needs to be a multiple of the target page size
816#                     and a power of 2
817#                     (Since 2.11)
818#
819# @max-postcopy-bandwidth: Background transfer bandwidth during postcopy.
820#                          Defaults to 0 (unlimited).  In bytes per second.
821#                          (Since 3.0)
822#
823# @max-cpu-throttle: maximum cpu throttle percentage.
824#                    The default value is 99. (Since 3.1)
825#
826# @multifd-compression: Which compression method to use.
827#                       Defaults to none. (Since 5.0)
828#
829# @multifd-zlib-level: Set the compression level to be used in live
830#          migration, the compression level is an integer between 0
831#          and 9, where 0 means no compression, 1 means the best
832#          compression speed, and 9 means best compression ratio which
833#          will consume more CPU.
834#          Defaults to 1. (Since 5.0)
835#
836# @multifd-zstd-level: Set the compression level to be used in live
837#          migration, the compression level is an integer between 0
838#          and 20, where 0 means no compression, 1 means the best
839#          compression speed, and 20 means best compression ratio which
840#          will consume more CPU.
841#          Defaults to 1. (Since 5.0)
842#
843# @block-bitmap-mapping: Maps block nodes and bitmaps on them to
844#          aliases for the purpose of dirty bitmap migration.  Such
845#          aliases may for example be the corresponding names on the
846#          opposite site.
847#          The mapping must be one-to-one, but not necessarily
848#          complete: On the source, unmapped bitmaps and all bitmaps
849#          on unmapped nodes will be ignored.  On the destination,
850#          encountering an unmapped alias in the incoming migration
851#          stream will result in a report, and all further bitmap
852#          migration data will then be discarded.
853#          Note that the destination does not know about bitmaps it
854#          does not receive, so there is no limitation or requirement
855#          regarding the number of bitmaps received, or how they are
856#          named, or on which nodes they are placed.
857#          By default (when this parameter has never been set), bitmap
858#          names are mapped to themselves.  Nodes are mapped to their
859#          block device name if there is one, and to their node name
860#          otherwise. (Since 5.2)
861#
862# Since: 2.4
863##
864# TODO either fuse back into MigrationParameters, or make
865# MigrationParameters members mandatory
866{ 'struct': 'MigrateSetParameters',
867  'data': { '*announce-initial': 'size',
868            '*announce-max': 'size',
869            '*announce-rounds': 'size',
870            '*announce-step': 'size',
871            '*compress-level': 'int',
872            '*compress-threads': 'int',
873            '*compress-wait-thread': 'bool',
874            '*decompress-threads': 'int',
875            '*throttle-trigger-threshold': 'int',
876            '*cpu-throttle-initial': 'int',
877            '*cpu-throttle-increment': 'int',
878            '*cpu-throttle-tailslow': 'bool',
879            '*tls-creds': 'StrOrNull',
880            '*tls-hostname': 'StrOrNull',
881            '*tls-authz': 'StrOrNull',
882            '*max-bandwidth': 'int',
883            '*downtime-limit': 'int',
884            '*x-checkpoint-delay': 'int',
885            '*block-incremental': 'bool',
886            '*multifd-channels': 'int',
887            '*xbzrle-cache-size': 'size',
888            '*max-postcopy-bandwidth': 'size',
889            '*max-cpu-throttle': 'int',
890            '*multifd-compression': 'MultiFDCompression',
891            '*multifd-zlib-level': 'int',
892            '*multifd-zstd-level': 'int',
893            '*block-bitmap-mapping': [ 'BitmapMigrationNodeAlias' ] } }
894
895##
896# @migrate-set-parameters:
897#
898# Set various migration parameters.
899#
900# Since: 2.4
901#
902# Example:
903#
904# -> { "execute": "migrate-set-parameters" ,
905#      "arguments": { "compress-level": 1 } }
906#
907##
908{ 'command': 'migrate-set-parameters', 'boxed': true,
909  'data': 'MigrateSetParameters' }
910
911##
912# @MigrationParameters:
913#
914# The optional members aren't actually optional.
915#
916# @announce-initial: Initial delay (in milliseconds) before sending the
917#                    first announce (Since 4.0)
918#
919# @announce-max: Maximum delay (in milliseconds) between packets in the
920#                announcement (Since 4.0)
921#
922# @announce-rounds: Number of self-announce packets sent after migration
923#                   (Since 4.0)
924#
925# @announce-step: Increase in delay (in milliseconds) between subsequent
926#                 packets in the announcement (Since 4.0)
927#
928# @compress-level: compression level
929#
930# @compress-threads: compression thread count
931#
932# @compress-wait-thread: Controls behavior when all compression threads are
933#                        currently busy. If true (default), wait for a free
934#                        compression thread to become available; otherwise,
935#                        send the page uncompressed. (Since 3.1)
936#
937# @decompress-threads: decompression thread count
938#
939# @throttle-trigger-threshold: The ratio of bytes_dirty_period and bytes_xfer_period
940#                              to trigger throttling. It is expressed as percentage.
941#                              The default value is 50. (Since 5.0)
942#
943# @cpu-throttle-initial: Initial percentage of time guest cpus are
944#                        throttled when migration auto-converge is activated.
945#                        (Since 2.7)
946#
947# @cpu-throttle-increment: throttle percentage increase each time
948#                          auto-converge detects that migration is not making
949#                          progress. (Since 2.7)
950#
951# @cpu-throttle-tailslow: Make CPU throttling slower at tail stage
952#                         At the tail stage of throttling, the Guest is very
953#                         sensitive to CPU percentage while the @cpu-throttle
954#                         -increment is excessive usually at tail stage.
955#                         If this parameter is true, we will compute the ideal
956#                         CPU percentage used by the Guest, which may exactly make
957#                         the dirty rate match the dirty rate threshold. Then we
958#                         will choose a smaller throttle increment between the
959#                         one specified by @cpu-throttle-increment and the one
960#                         generated by ideal CPU percentage.
961#                         Therefore, it is compatible to traditional throttling,
962#                         meanwhile the throttle increment won't be excessive
963#                         at tail stage.
964#                         The default value is false. (Since 5.1)
965#
966# @tls-creds: ID of the 'tls-creds' object that provides credentials
967#             for establishing a TLS connection over the migration data
968#             channel. On the outgoing side of the migration, the credentials
969#             must be for a 'client' endpoint, while for the incoming side the
970#             credentials must be for a 'server' endpoint.
971#             An empty string means that QEMU will use plain text mode for
972#             migration, rather than TLS (Since 2.7)
973#             Note: 2.8 reports this by omitting tls-creds instead.
974#
975# @tls-hostname: hostname of the target host for the migration. This
976#                is required when using x509 based TLS credentials and the
977#                migration URI does not already include a hostname. For
978#                example if using fd: or exec: based migration, the
979#                hostname must be provided so that the server's x509
980#                certificate identity can be validated. (Since 2.7)
981#                An empty string means that QEMU will use the hostname
982#                associated with the migration URI, if any. (Since 2.9)
983#                Note: 2.8 reports this by omitting tls-hostname instead.
984#
985# @tls-authz: ID of the 'authz' object subclass that provides access control
986#             checking of the TLS x509 certificate distinguished name. (Since
987#             4.0)
988#
989# @max-bandwidth: to set maximum speed for migration. maximum speed in
990#                 bytes per second. (Since 2.8)
991#
992# @downtime-limit: set maximum tolerated downtime for migration. maximum
993#                  downtime in milliseconds (Since 2.8)
994#
995# @x-checkpoint-delay: the delay time between two COLO checkpoints. (Since 2.8)
996#
997# @block-incremental: Affects how much storage is migrated when the
998#                     block migration capability is enabled.  When false, the entire
999#                     storage backing chain is migrated into a flattened image at
1000#                     the destination; when true, only the active qcow2 layer is
1001#                     migrated and the destination must already have access to the
1002#                     same backing chain as was used on the source.  (since 2.10)
1003#
1004# @multifd-channels: Number of channels used to migrate data in
1005#                    parallel. This is the same number that the
1006#                    number of sockets used for migration.
1007#                    The default value is 2 (since 4.0)
1008#
1009# @xbzrle-cache-size: cache size to be used by XBZRLE migration.  It
1010#                     needs to be a multiple of the target page size
1011#                     and a power of 2
1012#                     (Since 2.11)
1013#
1014# @max-postcopy-bandwidth: Background transfer bandwidth during postcopy.
1015#                          Defaults to 0 (unlimited).  In bytes per second.
1016#                          (Since 3.0)
1017#
1018# @max-cpu-throttle: maximum cpu throttle percentage.
1019#                    Defaults to 99.
1020#                    (Since 3.1)
1021#
1022# @multifd-compression: Which compression method to use.
1023#                       Defaults to none. (Since 5.0)
1024#
1025# @multifd-zlib-level: Set the compression level to be used in live
1026#          migration, the compression level is an integer between 0
1027#          and 9, where 0 means no compression, 1 means the best
1028#          compression speed, and 9 means best compression ratio which
1029#          will consume more CPU.
1030#          Defaults to 1. (Since 5.0)
1031#
1032# @multifd-zstd-level: Set the compression level to be used in live
1033#          migration, the compression level is an integer between 0
1034#          and 20, where 0 means no compression, 1 means the best
1035#          compression speed, and 20 means best compression ratio which
1036#          will consume more CPU.
1037#          Defaults to 1. (Since 5.0)
1038#
1039# @block-bitmap-mapping: Maps block nodes and bitmaps on them to
1040#          aliases for the purpose of dirty bitmap migration.  Such
1041#          aliases may for example be the corresponding names on the
1042#          opposite site.
1043#          The mapping must be one-to-one, but not necessarily
1044#          complete: On the source, unmapped bitmaps and all bitmaps
1045#          on unmapped nodes will be ignored.  On the destination,
1046#          encountering an unmapped alias in the incoming migration
1047#          stream will result in a report, and all further bitmap
1048#          migration data will then be discarded.
1049#          Note that the destination does not know about bitmaps it
1050#          does not receive, so there is no limitation or requirement
1051#          regarding the number of bitmaps received, or how they are
1052#          named, or on which nodes they are placed.
1053#          By default (when this parameter has never been set), bitmap
1054#          names are mapped to themselves.  Nodes are mapped to their
1055#          block device name if there is one, and to their node name
1056#          otherwise. (Since 5.2)
1057#
1058# Since: 2.4
1059##
1060{ 'struct': 'MigrationParameters',
1061  'data': { '*announce-initial': 'size',
1062            '*announce-max': 'size',
1063            '*announce-rounds': 'size',
1064            '*announce-step': 'size',
1065            '*compress-level': 'uint8',
1066            '*compress-threads': 'uint8',
1067            '*compress-wait-thread': 'bool',
1068            '*decompress-threads': 'uint8',
1069            '*throttle-trigger-threshold': 'uint8',
1070            '*cpu-throttle-initial': 'uint8',
1071            '*cpu-throttle-increment': 'uint8',
1072            '*cpu-throttle-tailslow': 'bool',
1073            '*tls-creds': 'str',
1074            '*tls-hostname': 'str',
1075            '*tls-authz': 'str',
1076            '*max-bandwidth': 'size',
1077            '*downtime-limit': 'uint64',
1078            '*x-checkpoint-delay': 'uint32',
1079            '*block-incremental': 'bool' ,
1080            '*multifd-channels': 'uint8',
1081            '*xbzrle-cache-size': 'size',
1082            '*max-postcopy-bandwidth': 'size',
1083            '*max-cpu-throttle': 'uint8',
1084            '*multifd-compression': 'MultiFDCompression',
1085            '*multifd-zlib-level': 'uint8',
1086            '*multifd-zstd-level': 'uint8',
1087            '*block-bitmap-mapping': [ 'BitmapMigrationNodeAlias' ] } }
1088
1089##
1090# @query-migrate-parameters:
1091#
1092# Returns information about the current migration parameters
1093#
1094# Returns: @MigrationParameters
1095#
1096# Since: 2.4
1097#
1098# Example:
1099#
1100# -> { "execute": "query-migrate-parameters" }
1101# <- { "return": {
1102#          "decompress-threads": 2,
1103#          "cpu-throttle-increment": 10,
1104#          "compress-threads": 8,
1105#          "compress-level": 1,
1106#          "cpu-throttle-initial": 20,
1107#          "max-bandwidth": 33554432,
1108#          "downtime-limit": 300
1109#       }
1110#    }
1111#
1112##
1113{ 'command': 'query-migrate-parameters',
1114  'returns': 'MigrationParameters' }
1115
1116##
1117# @client_migrate_info:
1118#
1119# Set migration information for remote display.  This makes the server
1120# ask the client to automatically reconnect using the new parameters
1121# once migration finished successfully.  Only implemented for SPICE.
1122#
1123# @protocol:     must be "spice"
1124# @hostname:     migration target hostname
1125# @port:         spice tcp port for plaintext channels
1126# @tls-port:     spice tcp port for tls-secured channels
1127# @cert-subject: server certificate subject
1128#
1129# Since: 0.14.0
1130#
1131# Example:
1132#
1133# -> { "execute": "client_migrate_info",
1134#      "arguments": { "protocol": "spice",
1135#                     "hostname": "virt42.lab.kraxel.org",
1136#                     "port": 1234 } }
1137# <- { "return": {} }
1138#
1139##
1140{ 'command': 'client_migrate_info',
1141  'data': { 'protocol': 'str', 'hostname': 'str', '*port': 'int',
1142            '*tls-port': 'int', '*cert-subject': 'str' } }
1143
1144##
1145# @migrate-start-postcopy:
1146#
1147# Followup to a migration command to switch the migration to postcopy mode.
1148# The postcopy-ram capability must be set on both source and destination
1149# before the original migration command.
1150#
1151# Since: 2.5
1152#
1153# Example:
1154#
1155# -> { "execute": "migrate-start-postcopy" }
1156# <- { "return": {} }
1157#
1158##
1159{ 'command': 'migrate-start-postcopy' }
1160
1161##
1162# @MIGRATION:
1163#
1164# Emitted when a migration event happens
1165#
1166# @status: @MigrationStatus describing the current migration status.
1167#
1168# Since: 2.4
1169#
1170# Example:
1171#
1172# <- {"timestamp": {"seconds": 1432121972, "microseconds": 744001},
1173#     "event": "MIGRATION",
1174#     "data": {"status": "completed"} }
1175#
1176##
1177{ 'event': 'MIGRATION',
1178  'data': {'status': 'MigrationStatus'}}
1179
1180##
1181# @MIGRATION_PASS:
1182#
1183# Emitted from the source side of a migration at the start of each pass
1184# (when it syncs the dirty bitmap)
1185#
1186# @pass: An incrementing count (starting at 1 on the first pass)
1187#
1188# Since: 2.6
1189#
1190# Example:
1191#
1192# { "timestamp": {"seconds": 1449669631, "microseconds": 239225},
1193#   "event": "MIGRATION_PASS", "data": {"pass": 2} }
1194#
1195##
1196{ 'event': 'MIGRATION_PASS',
1197  'data': { 'pass': 'int' } }
1198
1199##
1200# @COLOMessage:
1201#
1202# The message transmission between Primary side and Secondary side.
1203#
1204# @checkpoint-ready: Secondary VM (SVM) is ready for checkpointing
1205#
1206# @checkpoint-request: Primary VM (PVM) tells SVM to prepare for checkpointing
1207#
1208# @checkpoint-reply: SVM gets PVM's checkpoint request
1209#
1210# @vmstate-send: VM's state will be sent by PVM.
1211#
1212# @vmstate-size: The total size of VMstate.
1213#
1214# @vmstate-received: VM's state has been received by SVM.
1215#
1216# @vmstate-loaded: VM's state has been loaded by SVM.
1217#
1218# Since: 2.8
1219##
1220{ 'enum': 'COLOMessage',
1221  'data': [ 'checkpoint-ready', 'checkpoint-request', 'checkpoint-reply',
1222            'vmstate-send', 'vmstate-size', 'vmstate-received',
1223            'vmstate-loaded' ] }
1224
1225##
1226# @COLOMode:
1227#
1228# The COLO current mode.
1229#
1230# @none: COLO is disabled.
1231#
1232# @primary: COLO node in primary side.
1233#
1234# @secondary: COLO node in slave side.
1235#
1236# Since: 2.8
1237##
1238{ 'enum': 'COLOMode',
1239  'data': [ 'none', 'primary', 'secondary'] }
1240
1241##
1242# @FailoverStatus:
1243#
1244# An enumeration of COLO failover status
1245#
1246# @none: no failover has ever happened
1247#
1248# @require: got failover requirement but not handled
1249#
1250# @active: in the process of doing failover
1251#
1252# @completed: finish the process of failover
1253#
1254# @relaunch: restart the failover process, from 'none' -> 'completed' (Since 2.9)
1255#
1256# Since: 2.8
1257##
1258{ 'enum': 'FailoverStatus',
1259  'data': [ 'none', 'require', 'active', 'completed', 'relaunch' ] }
1260
1261##
1262# @COLO_EXIT:
1263#
1264# Emitted when VM finishes COLO mode due to some errors happening or
1265# at the request of users.
1266#
1267# @mode: report COLO mode when COLO exited.
1268#
1269# @reason: describes the reason for the COLO exit.
1270#
1271# Since: 3.1
1272#
1273# Example:
1274#
1275# <- { "timestamp": {"seconds": 2032141960, "microseconds": 417172},
1276#      "event": "COLO_EXIT", "data": {"mode": "primary", "reason": "request" } }
1277#
1278##
1279{ 'event': 'COLO_EXIT',
1280  'data': {'mode': 'COLOMode', 'reason': 'COLOExitReason' } }
1281
1282##
1283# @COLOExitReason:
1284#
1285# The reason for a COLO exit.
1286#
1287# @none: failover has never happened. This state does not occur
1288#        in the COLO_EXIT event, and is only visible in the result of
1289#        query-colo-status.
1290#
1291# @request: COLO exit is due to an external request.
1292#
1293# @error: COLO exit is due to an internal error.
1294#
1295# @processing: COLO is currently handling a failover (since 4.0).
1296#
1297# Since: 3.1
1298##
1299{ 'enum': 'COLOExitReason',
1300  'data': [ 'none', 'request', 'error' , 'processing' ] }
1301
1302##
1303# @x-colo-lost-heartbeat:
1304#
1305# Tell qemu that heartbeat is lost, request it to do takeover procedures.
1306# If this command is sent to the PVM, the Primary side will exit COLO mode.
1307# If sent to the Secondary, the Secondary side will run failover work,
1308# then takes over server operation to become the service VM.
1309#
1310# Since: 2.8
1311#
1312# Example:
1313#
1314# -> { "execute": "x-colo-lost-heartbeat" }
1315# <- { "return": {} }
1316#
1317##
1318{ 'command': 'x-colo-lost-heartbeat' }
1319
1320##
1321# @migrate_cancel:
1322#
1323# Cancel the current executing migration process.
1324#
1325# Returns: nothing on success
1326#
1327# Notes: This command succeeds even if there is no migration process running.
1328#
1329# Since: 0.14.0
1330#
1331# Example:
1332#
1333# -> { "execute": "migrate_cancel" }
1334# <- { "return": {} }
1335#
1336##
1337{ 'command': 'migrate_cancel' }
1338
1339##
1340# @migrate-continue:
1341#
1342# Continue migration when it's in a paused state.
1343#
1344# @state: The state the migration is currently expected to be in
1345#
1346# Returns: nothing on success
1347# Since: 2.11
1348# Example:
1349#
1350# -> { "execute": "migrate-continue" , "arguments":
1351#      { "state": "pre-switchover" } }
1352# <- { "return": {} }
1353##
1354{ 'command': 'migrate-continue', 'data': {'state': 'MigrationStatus'} }
1355
1356##
1357# @migrate_set_downtime:
1358#
1359# Set maximum tolerated downtime for migration.
1360#
1361# @value: maximum downtime in seconds
1362#
1363# Features:
1364# @deprecated: This command is deprecated.  Use
1365#     'migrate-set-parameters' instead.
1366#
1367# Returns: nothing on success
1368#
1369# Since: 0.14.0
1370#
1371# Example:
1372#
1373# -> { "execute": "migrate_set_downtime", "arguments": { "value": 0.1 } }
1374# <- { "return": {} }
1375#
1376##
1377{ 'command': 'migrate_set_downtime', 'data': {'value': 'number'},
1378  'features': [ 'deprecated' ] }
1379
1380##
1381# @migrate_set_speed:
1382#
1383# Set maximum speed for migration.
1384#
1385# @value: maximum speed in bytes per second.
1386#
1387# Features:
1388# @deprecated: This command is deprecated.  Use
1389#     'migrate-set-parameters' instead.
1390#
1391# Returns: nothing on success
1392#
1393# Since: 0.14.0
1394#
1395# Example:
1396#
1397# -> { "execute": "migrate_set_speed", "arguments": { "value": 1024 } }
1398# <- { "return": {} }
1399#
1400##
1401{ 'command': 'migrate_set_speed', 'data': {'value': 'int'},
1402  'features': [ 'deprecated' ] }
1403
1404##
1405# @migrate-set-cache-size:
1406#
1407# Set cache size to be used by XBZRLE migration
1408#
1409# @value: cache size in bytes
1410#
1411# Features:
1412# @deprecated: This command is deprecated.  Use
1413#     'migrate-set-parameters' instead.
1414#
1415# The size will be rounded down to the nearest power of 2.
1416# The cache size can be modified before and during ongoing migration
1417#
1418# Returns: nothing on success
1419#
1420# Since: 1.2
1421#
1422# Example:
1423#
1424# -> { "execute": "migrate-set-cache-size",
1425#      "arguments": { "value": 536870912 } }
1426# <- { "return": {} }
1427#
1428##
1429{ 'command': 'migrate-set-cache-size', 'data': {'value': 'int'},
1430  'features': [ 'deprecated' ] }
1431
1432##
1433# @query-migrate-cache-size:
1434#
1435# Query migration XBZRLE cache size
1436#
1437# Features:
1438# @deprecated: This command is deprecated.  Use
1439#     'query-migrate-parameters' instead.
1440#
1441# Returns: XBZRLE cache size in bytes
1442#
1443# Since: 1.2
1444#
1445# Example:
1446#
1447# -> { "execute": "query-migrate-cache-size" }
1448# <- { "return": 67108864 }
1449#
1450##
1451{ 'command': 'query-migrate-cache-size', 'returns': 'int',
1452  'features': [ 'deprecated' ] }
1453
1454##
1455# @migrate:
1456#
1457# Migrates the current running guest to another Virtual Machine.
1458#
1459# @uri: the Uniform Resource Identifier of the destination VM
1460#
1461# @blk: do block migration (full disk copy)
1462#
1463# @inc: incremental disk copy migration
1464#
1465# @detach: this argument exists only for compatibility reasons and
1466#          is ignored by QEMU
1467#
1468# @resume: resume one paused migration, default "off". (since 3.0)
1469#
1470# Returns: nothing on success
1471#
1472# Since: 0.14.0
1473#
1474# Notes:
1475#
1476# 1. The 'query-migrate' command should be used to check migration's progress
1477#    and final result (this information is provided by the 'status' member)
1478#
1479# 2. All boolean arguments default to false
1480#
1481# 3. The user Monitor's "detach" argument is invalid in QMP and should not
1482#    be used
1483#
1484# Example:
1485#
1486# -> { "execute": "migrate", "arguments": { "uri": "tcp:0:4446" } }
1487# <- { "return": {} }
1488#
1489##
1490{ 'command': 'migrate',
1491  'data': {'uri': 'str', '*blk': 'bool', '*inc': 'bool',
1492           '*detach': 'bool', '*resume': 'bool' } }
1493
1494##
1495# @migrate-incoming:
1496#
1497# Start an incoming migration, the qemu must have been started
1498# with -incoming defer
1499#
1500# @uri: The Uniform Resource Identifier identifying the source or
1501#       address to listen on
1502#
1503# Returns: nothing on success
1504#
1505# Since: 2.3
1506#
1507# Notes:
1508#
1509# 1. It's a bad idea to use a string for the uri, but it needs to stay
1510#    compatible with -incoming and the format of the uri is already exposed
1511#    above libvirt.
1512#
1513# 2. QEMU must be started with -incoming defer to allow migrate-incoming to
1514#    be used.
1515#
1516# 3. The uri format is the same as for -incoming
1517#
1518# Example:
1519#
1520# -> { "execute": "migrate-incoming",
1521#      "arguments": { "uri": "tcp::4446" } }
1522# <- { "return": {} }
1523#
1524##
1525{ 'command': 'migrate-incoming', 'data': {'uri': 'str' } }
1526
1527##
1528# @xen-save-devices-state:
1529#
1530# Save the state of all devices to file. The RAM and the block devices
1531# of the VM are not saved by this command.
1532#
1533# @filename: the file to save the state of the devices to as binary
1534#            data. See xen-save-devices-state.txt for a description of the binary
1535#            format.
1536#
1537# @live: Optional argument to ask QEMU to treat this command as part of a live
1538#        migration. Default to true. (since 2.11)
1539#
1540# Returns: Nothing on success
1541#
1542# Since: 1.1
1543#
1544# Example:
1545#
1546# -> { "execute": "xen-save-devices-state",
1547#      "arguments": { "filename": "/tmp/save" } }
1548# <- { "return": {} }
1549#
1550##
1551{ 'command': 'xen-save-devices-state',
1552  'data': {'filename': 'str', '*live':'bool' } }
1553
1554##
1555# @xen-set-replication:
1556#
1557# Enable or disable replication.
1558#
1559# @enable: true to enable, false to disable.
1560#
1561# @primary: true for primary or false for secondary.
1562#
1563# @failover: true to do failover, false to stop. but cannot be
1564#            specified if 'enable' is true. default value is false.
1565#
1566# Returns: nothing.
1567#
1568# Example:
1569#
1570# -> { "execute": "xen-set-replication",
1571#      "arguments": {"enable": true, "primary": false} }
1572# <- { "return": {} }
1573#
1574# Since: 2.9
1575##
1576{ 'command': 'xen-set-replication',
1577  'data': { 'enable': 'bool', 'primary': 'bool', '*failover' : 'bool' },
1578  'if': 'defined(CONFIG_REPLICATION)' }
1579
1580##
1581# @ReplicationStatus:
1582#
1583# The result format for 'query-xen-replication-status'.
1584#
1585# @error: true if an error happened, false if replication is normal.
1586#
1587# @desc: the human readable error description string, when
1588#        @error is 'true'.
1589#
1590# Since: 2.9
1591##
1592{ 'struct': 'ReplicationStatus',
1593  'data': { 'error': 'bool', '*desc': 'str' },
1594  'if': 'defined(CONFIG_REPLICATION)' }
1595
1596##
1597# @query-xen-replication-status:
1598#
1599# Query replication status while the vm is running.
1600#
1601# Returns: A @ReplicationResult object showing the status.
1602#
1603# Example:
1604#
1605# -> { "execute": "query-xen-replication-status" }
1606# <- { "return": { "error": false } }
1607#
1608# Since: 2.9
1609##
1610{ 'command': 'query-xen-replication-status',
1611  'returns': 'ReplicationStatus',
1612  'if': 'defined(CONFIG_REPLICATION)' }
1613
1614##
1615# @xen-colo-do-checkpoint:
1616#
1617# Xen uses this command to notify replication to trigger a checkpoint.
1618#
1619# Returns: nothing.
1620#
1621# Example:
1622#
1623# -> { "execute": "xen-colo-do-checkpoint" }
1624# <- { "return": {} }
1625#
1626# Since: 2.9
1627##
1628{ 'command': 'xen-colo-do-checkpoint',
1629  'if': 'defined(CONFIG_REPLICATION)' }
1630
1631##
1632# @COLOStatus:
1633#
1634# The result format for 'query-colo-status'.
1635#
1636# @mode: COLO running mode. If COLO is running, this field will return
1637#        'primary' or 'secondary'.
1638#
1639# @last-mode: COLO last running mode. If COLO is running, this field
1640#             will return same like mode field, after failover we can
1641#             use this field to get last colo mode. (since 4.0)
1642#
1643# @reason: describes the reason for the COLO exit.
1644#
1645# Since: 3.1
1646##
1647{ 'struct': 'COLOStatus',
1648  'data': { 'mode': 'COLOMode', 'last-mode': 'COLOMode',
1649            'reason': 'COLOExitReason' } }
1650
1651##
1652# @query-colo-status:
1653#
1654# Query COLO status while the vm is running.
1655#
1656# Returns: A @COLOStatus object showing the status.
1657#
1658# Example:
1659#
1660# -> { "execute": "query-colo-status" }
1661# <- { "return": { "mode": "primary", "reason": "request" } }
1662#
1663# Since: 3.1
1664##
1665{ 'command': 'query-colo-status',
1666  'returns': 'COLOStatus' }
1667
1668##
1669# @migrate-recover:
1670#
1671# Provide a recovery migration stream URI.
1672#
1673# @uri: the URI to be used for the recovery of migration stream.
1674#
1675# Returns: nothing.
1676#
1677# Example:
1678#
1679# -> { "execute": "migrate-recover",
1680#      "arguments": { "uri": "tcp:192.168.1.200:12345" } }
1681# <- { "return": {} }
1682#
1683# Since: 3.0
1684##
1685{ 'command': 'migrate-recover',
1686  'data': { 'uri': 'str' },
1687  'allow-oob': true }
1688
1689##
1690# @migrate-pause:
1691#
1692# Pause a migration.  Currently it only supports postcopy.
1693#
1694# Returns: nothing.
1695#
1696# Example:
1697#
1698# -> { "execute": "migrate-pause" }
1699# <- { "return": {} }
1700#
1701# Since: 3.0
1702##
1703{ 'command': 'migrate-pause', 'allow-oob': true }
1704
1705##
1706# @UNPLUG_PRIMARY:
1707#
1708# Emitted from source side of a migration when migration state is
1709# WAIT_UNPLUG. Device was unplugged by guest operating system.
1710# Device resources in QEMU are kept on standby to be able to re-plug it in case
1711# of migration failure.
1712#
1713# @device-id: QEMU device id of the unplugged device
1714#
1715# Since: 4.2
1716#
1717# Example:
1718#   {"event": "UNPLUG_PRIMARY", "data": {"device-id": "hostdev0"} }
1719#
1720##
1721{ 'event': 'UNPLUG_PRIMARY',
1722  'data': { 'device-id': 'str' } }
1723