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