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