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