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