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