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