1# -*- Mode: Python -*- 2# 3 4## 5# = Migration 6## 7 8{ 'include': 'common.json' } 9 10## 11# @MigrationStats: 12# 13# Detailed migration status. 14# 15# @transferred: amount of bytes already transferred to the target VM 16# 17# @remaining: amount of bytes remaining to be transferred to the target VM 18# 19# @total: total amount of bytes involved in the migration process 20# 21# @duplicate: number of duplicate (zero) pages (since 1.2) 22# 23# @skipped: number of skipped zero pages (since 1.5) 24# 25# @normal: number of normal pages (since 1.2) 26# 27# @normal-bytes: number of normal bytes sent (since 1.2) 28# 29# @dirty-pages-rate: number of pages dirtied by second by the 30# guest (since 1.3) 31# 32# @mbps: throughput in megabits/sec. (since 1.6) 33# 34# @dirty-sync-count: number of times that dirty ram was synchronized (since 2.1) 35# 36# @postcopy-requests: The number of page requests received from the destination 37# (since 2.7) 38# 39# @page-size: The number of bytes per page for the various page-based 40# statistics (since 2.10) 41# 42# Since: 0.14.0 43## 44{ 'struct': 'MigrationStats', 45 'data': {'transferred': 'int', 'remaining': 'int', 'total': 'int' , 46 'duplicate': 'int', 'skipped': 'int', 'normal': 'int', 47 'normal-bytes': 'int', 'dirty-pages-rate' : 'int', 48 'mbps' : 'number', 'dirty-sync-count' : 'int', 49 'postcopy-requests' : 'int', 'page-size' : 'int' } } 50 51## 52# @XBZRLECacheStats: 53# 54# Detailed XBZRLE migration cache statistics 55# 56# @cache-size: XBZRLE cache size 57# 58# @bytes: amount of bytes already transferred to the target VM 59# 60# @pages: amount of pages transferred to the target VM 61# 62# @cache-miss: number of cache miss 63# 64# @cache-miss-rate: rate of cache miss (since 2.1) 65# 66# @overflow: number of overflows 67# 68# Since: 1.2 69## 70{ 'struct': 'XBZRLECacheStats', 71 'data': {'cache-size': 'int', 'bytes': 'int', 'pages': 'int', 72 'cache-miss': 'int', 'cache-miss-rate': 'number', 73 'overflow': 'int' } } 74 75## 76# @MigrationStatus: 77# 78# An enumeration of migration status. 79# 80# @none: no migration has ever happened. 81# 82# @setup: migration process has been initiated. 83# 84# @cancelling: in the process of cancelling migration. 85# 86# @cancelled: cancelling migration is finished. 87# 88# @active: in the process of doing migration. 89# 90# @postcopy-active: like active, but now in postcopy mode. (since 2.5) 91# 92# @postcopy-paused: during postcopy but paused. (since 3.0) 93# 94# @postcopy-recover: trying to recover from a paused postcopy. (since 3.0) 95# 96# @completed: migration is finished. 97# 98# @failed: some error occurred during migration process. 99# 100# @colo: VM is in the process of fault tolerance, VM can not get into this 101# state unless colo capability is enabled for migration. (since 2.8) 102# 103# @pre-switchover: Paused before device serialisation. (since 2.11) 104# 105# @device: During device serialisation when pause-before-switchover is enabled 106# (since 2.11) 107# 108# Since: 2.3 109# 110## 111{ 'enum': 'MigrationStatus', 112 'data': [ 'none', 'setup', 'cancelling', 'cancelled', 113 'active', 'postcopy-active', 'postcopy-paused', 114 'postcopy-recover', 'completed', 'failed', 'colo', 115 'pre-switchover', 'device' ] } 116 117## 118# @MigrationInfo: 119# 120# Information about current migration process. 121# 122# @status: @MigrationStatus describing the current migration status. 123# If this field is not returned, no migration process 124# has been initiated 125# 126# @ram: @MigrationStats containing detailed migration 127# status, only returned if status is 'active' or 128# 'completed'(since 1.2) 129# 130# @disk: @MigrationStats containing detailed disk migration 131# status, only returned if status is 'active' and it is a block 132# migration 133# 134# @xbzrle-cache: @XBZRLECacheStats containing detailed XBZRLE 135# migration statistics, only returned if XBZRLE feature is on and 136# status is 'active' or 'completed' (since 1.2) 137# 138# @total-time: total amount of milliseconds since migration started. 139# If migration has ended, it returns the total migration 140# time. (since 1.2) 141# 142# @downtime: only present when migration finishes correctly 143# total downtime in milliseconds for the guest. 144# (since 1.3) 145# 146# @expected-downtime: only present while migration is active 147# expected downtime in milliseconds for the guest in last walk 148# of the dirty bitmap. (since 1.3) 149# 150# @setup-time: amount of setup time in milliseconds _before_ the 151# iterations begin but _after_ the QMP command is issued. This is designed 152# to provide an accounting of any activities (such as RDMA pinning) which 153# may be expensive, but do not actually occur during the iterative 154# migration rounds themselves. (since 1.6) 155# 156# @cpu-throttle-percentage: percentage of time guest cpus are being 157# throttled during auto-converge. This is only present when auto-converge 158# has started throttling guest cpus. (Since 2.7) 159# 160# @error-desc: the human readable error description string, when 161# @status is 'failed'. Clients should not attempt to parse the 162# error strings. (Since 2.7) 163# 164# @postcopy-blocktime: total time when all vCPU were blocked during postcopy 165# live migration. This is only present when the postcopy-blocktime 166# migration capability is enabled. (Since 3.0) 167# 168# @postcopy-vcpu-blocktime: list of the postcopy blocktime per vCPU. This is 169# only present when the postcopy-blocktime migration capability 170# is enabled. (Since 3.0) 171# 172# 173# Since: 0.14.0 174## 175{ 'struct': 'MigrationInfo', 176 'data': {'*status': 'MigrationStatus', '*ram': 'MigrationStats', 177 '*disk': 'MigrationStats', 178 '*xbzrle-cache': 'XBZRLECacheStats', 179 '*total-time': 'int', 180 '*expected-downtime': 'int', 181 '*downtime': 'int', 182 '*setup-time': 'int', 183 '*cpu-throttle-percentage': 'int', 184 '*error-desc': 'str', 185 '*postcopy-blocktime' : 'uint32', 186 '*postcopy-vcpu-blocktime': ['uint32']} } 187 188## 189# @query-migrate: 190# 191# Returns information about current migration process. If migration 192# is active there will be another json-object with RAM migration 193# status and if block migration is active another one with block 194# migration status. 195# 196# Returns: @MigrationInfo 197# 198# Since: 0.14.0 199# 200# Example: 201# 202# 1. Before the first migration 203# 204# -> { "execute": "query-migrate" } 205# <- { "return": {} } 206# 207# 2. Migration is done and has succeeded 208# 209# -> { "execute": "query-migrate" } 210# <- { "return": { 211# "status": "completed", 212# "ram":{ 213# "transferred":123, 214# "remaining":123, 215# "total":246, 216# "total-time":12345, 217# "setup-time":12345, 218# "downtime":12345, 219# "duplicate":123, 220# "normal":123, 221# "normal-bytes":123456, 222# "dirty-sync-count":15 223# } 224# } 225# } 226# 227# 3. Migration is done and has failed 228# 229# -> { "execute": "query-migrate" } 230# <- { "return": { "status": "failed" } } 231# 232# 4. Migration is being performed and is not a block migration: 233# 234# -> { "execute": "query-migrate" } 235# <- { 236# "return":{ 237# "status":"active", 238# "ram":{ 239# "transferred":123, 240# "remaining":123, 241# "total":246, 242# "total-time":12345, 243# "setup-time":12345, 244# "expected-downtime":12345, 245# "duplicate":123, 246# "normal":123, 247# "normal-bytes":123456, 248# "dirty-sync-count":15 249# } 250# } 251# } 252# 253# 5. Migration is being performed and is a block migration: 254# 255# -> { "execute": "query-migrate" } 256# <- { 257# "return":{ 258# "status":"active", 259# "ram":{ 260# "total":1057024, 261# "remaining":1053304, 262# "transferred":3720, 263# "total-time":12345, 264# "setup-time":12345, 265# "expected-downtime":12345, 266# "duplicate":123, 267# "normal":123, 268# "normal-bytes":123456, 269# "dirty-sync-count":15 270# }, 271# "disk":{ 272# "total":20971520, 273# "remaining":20880384, 274# "transferred":91136 275# } 276# } 277# } 278# 279# 6. Migration is being performed and XBZRLE is active: 280# 281# -> { "execute": "query-migrate" } 282# <- { 283# "return":{ 284# "status":"active", 285# "capabilities" : [ { "capability": "xbzrle", "state" : true } ], 286# "ram":{ 287# "total":1057024, 288# "remaining":1053304, 289# "transferred":3720, 290# "total-time":12345, 291# "setup-time":12345, 292# "expected-downtime":12345, 293# "duplicate":10, 294# "normal":3333, 295# "normal-bytes":3412992, 296# "dirty-sync-count":15 297# }, 298# "xbzrle-cache":{ 299# "cache-size":67108864, 300# "bytes":20971520, 301# "pages":2444343, 302# "cache-miss":2244, 303# "cache-miss-rate":0.123, 304# "overflow":34434 305# } 306# } 307# } 308# 309## 310{ 'command': 'query-migrate', 'returns': 'MigrationInfo' } 311 312## 313# @MigrationCapability: 314# 315# Migration capabilities enumeration 316# 317# @xbzrle: Migration supports xbzrle (Xor Based Zero Run Length Encoding). 318# This feature allows us to minimize migration traffic for certain work 319# loads, by sending compressed difference of the pages 320# 321# @rdma-pin-all: Controls whether or not the entire VM memory footprint is 322# mlock()'d on demand or all at once. Refer to docs/rdma.txt for usage. 323# Disabled by default. (since 2.0) 324# 325# @zero-blocks: During storage migration encode blocks of zeroes efficiently. This 326# essentially saves 1MB of zeroes per block on the wire. Enabling requires 327# source and target VM to support this feature. To enable it is sufficient 328# to enable the capability on the source VM. The feature is disabled by 329# default. (since 1.6) 330# 331# @compress: Use multiple compression threads to accelerate live migration. 332# This feature can help to reduce the migration traffic, by sending 333# compressed pages. Please note that if compress and xbzrle are both 334# on, compress only takes effect in the ram bulk stage, after that, 335# it will be disabled and only xbzrle takes effect, this can help to 336# minimize migration traffic. The feature is disabled by default. 337# (since 2.4 ) 338# 339# @events: generate events for each migration state change 340# (since 2.4 ) 341# 342# @auto-converge: If enabled, QEMU will automatically throttle down the guest 343# to speed up convergence of RAM migration. (since 1.6) 344# 345# @postcopy-ram: Start executing on the migration target before all of RAM has 346# been migrated, pulling the remaining pages along as needed. The 347# capacity must have the same setting on both source and target 348# or migration will not even start. NOTE: If the migration fails during 349# postcopy the VM will fail. (since 2.6) 350# 351# @x-colo: If enabled, migration will never end, and the state of the VM on the 352# primary side will be migrated continuously to the VM on secondary 353# side, this process is called COarse-Grain LOck Stepping (COLO) for 354# Non-stop Service. (since 2.8) 355# 356# @release-ram: if enabled, qemu will free the migrated ram pages on the source 357# during postcopy-ram migration. (since 2.9) 358# 359# @block: If enabled, QEMU will also migrate the contents of all block 360# devices. Default is disabled. A possible alternative uses 361# mirror jobs to a builtin NBD server on the destination, which 362# offers more flexibility. 363# (Since 2.10) 364# 365# @return-path: If enabled, migration will use the return path even 366# for precopy. (since 2.10) 367# 368# @pause-before-switchover: Pause outgoing migration before serialising device 369# state and before disabling block IO (since 2.11) 370# 371# @x-multifd: Use more than one fd for migration (since 2.11) 372# 373# @dirty-bitmaps: If enabled, QEMU will migrate named dirty bitmaps. 374# (since 2.12) 375# 376# @postcopy-blocktime: Calculate downtime for postcopy live migration 377# (since 3.0) 378# 379# @late-block-activate: If enabled, the destination will not activate block 380# devices (and thus take locks) immediately at the end of migration. 381# (since 3.0) 382# 383# Since: 1.2 384## 385{ 'enum': 'MigrationCapability', 386 'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks', 387 'compress', 'events', 'postcopy-ram', 'x-colo', 'release-ram', 388 'block', 'return-path', 'pause-before-switchover', 'x-multifd', 389 'dirty-bitmaps', 'postcopy-blocktime', 'late-block-activate' ] } 390 391## 392# @MigrationCapabilityStatus: 393# 394# Migration capability information 395# 396# @capability: capability enum 397# 398# @state: capability state bool 399# 400# Since: 1.2 401## 402{ 'struct': 'MigrationCapabilityStatus', 403 'data': { 'capability' : 'MigrationCapability', 'state' : 'bool' } } 404 405## 406# @migrate-set-capabilities: 407# 408# Enable/Disable the following migration capabilities (like xbzrle) 409# 410# @capabilities: json array of capability modifications to make 411# 412# Since: 1.2 413# 414# Example: 415# 416# -> { "execute": "migrate-set-capabilities" , "arguments": 417# { "capabilities": [ { "capability": "xbzrle", "state": true } ] } } 418# 419## 420{ 'command': 'migrate-set-capabilities', 421 'data': { 'capabilities': ['MigrationCapabilityStatus'] } } 422 423## 424# @query-migrate-capabilities: 425# 426# Returns information about the current migration capabilities status 427# 428# Returns: @MigrationCapabilitiesStatus 429# 430# Since: 1.2 431# 432# Example: 433# 434# -> { "execute": "query-migrate-capabilities" } 435# <- { "return": [ 436# {"state": false, "capability": "xbzrle"}, 437# {"state": false, "capability": "rdma-pin-all"}, 438# {"state": false, "capability": "auto-converge"}, 439# {"state": false, "capability": "zero-blocks"}, 440# {"state": false, "capability": "compress"}, 441# {"state": true, "capability": "events"}, 442# {"state": false, "capability": "postcopy-ram"}, 443# {"state": false, "capability": "x-colo"} 444# ]} 445# 446## 447{ 'command': 'query-migrate-capabilities', 'returns': ['MigrationCapabilityStatus']} 448 449## 450# @MigrationParameter: 451# 452# Migration parameters enumeration 453# 454# @compress-level: Set the compression level to be used in live migration, 455# the compression level is an integer between 0 and 9, where 0 means 456# no compression, 1 means the best compression speed, and 9 means best 457# compression ratio which will consume more CPU. 458# 459# @compress-threads: Set compression thread count to be used in live migration, 460# the compression thread count is an integer between 1 and 255. 461# 462# @decompress-threads: Set decompression thread count to be used in live 463# migration, the decompression thread count is an integer between 1 464# and 255. Usually, decompression is at least 4 times as fast as 465# compression, so set the decompress-threads to the number about 1/4 466# of compress-threads is adequate. 467# 468# @cpu-throttle-initial: Initial percentage of time guest cpus are throttled 469# when migration auto-converge is activated. The 470# default value is 20. (Since 2.7) 471# 472# @cpu-throttle-increment: throttle percentage increase each time 473# auto-converge detects that migration is not making 474# progress. The default value is 10. (Since 2.7) 475# 476# @tls-creds: ID of the 'tls-creds' object that provides credentials for 477# establishing a TLS connection over the migration data channel. 478# On the outgoing side of the migration, the credentials must 479# be for a 'client' endpoint, while for the incoming side the 480# credentials must be for a 'server' endpoint. Setting this 481# will enable TLS for all migrations. The default is unset, 482# resulting in unsecured migration at the QEMU level. (Since 2.7) 483# 484# @tls-hostname: hostname of the target host for the migration. This is 485# required when using x509 based TLS credentials and the 486# migration URI does not already include a hostname. For 487# example if using fd: or exec: based migration, the 488# hostname must be provided so that the server's x509 489# certificate identity can be validated. (Since 2.7) 490# 491# @max-bandwidth: to set maximum speed for migration. maximum speed in 492# bytes per second. (Since 2.8) 493# 494# @downtime-limit: set maximum tolerated downtime for migration. maximum 495# downtime in milliseconds (Since 2.8) 496# 497# @x-checkpoint-delay: The delay time (in ms) between two COLO checkpoints in 498# periodic mode. (Since 2.8) 499# 500# @block-incremental: Affects how much storage is migrated when the 501# block migration capability is enabled. When false, the entire 502# storage backing chain is migrated into a flattened image at 503# the destination; when true, only the active qcow2 layer is 504# migrated and the destination must already have access to the 505# same backing chain as was used on the source. (since 2.10) 506# 507# @x-multifd-channels: Number of channels used to migrate data in 508# parallel. This is the same number that the 509# number of sockets used for migration. The 510# default value is 2 (since 2.11) 511# 512# @x-multifd-page-count: Number of pages sent together to a thread. 513# The default value is 16 (since 2.11) 514# 515# @xbzrle-cache-size: cache size to be used by XBZRLE migration. It 516# needs to be a multiple of the target page size 517# and a power of 2 518# (Since 2.11) 519# 520# Since: 2.4 521## 522{ 'enum': 'MigrationParameter', 523 'data': ['compress-level', 'compress-threads', 'decompress-threads', 524 'cpu-throttle-initial', 'cpu-throttle-increment', 525 'tls-creds', 'tls-hostname', 'max-bandwidth', 526 'downtime-limit', 'x-checkpoint-delay', 'block-incremental', 527 'x-multifd-channels', 'x-multifd-page-count', 528 'xbzrle-cache-size' ] } 529 530## 531# @MigrateSetParameters: 532# 533# @compress-level: compression level 534# 535# @compress-threads: compression thread count 536# 537# @decompress-threads: decompression thread count 538# 539# @cpu-throttle-initial: Initial percentage of time guest cpus are 540# throttled when migration auto-converge is activated. 541# The default value is 20. (Since 2.7) 542# 543# @cpu-throttle-increment: throttle percentage increase each time 544# auto-converge detects that migration is not making 545# progress. The default value is 10. (Since 2.7) 546# 547# @tls-creds: ID of the 'tls-creds' object that provides credentials 548# for establishing a TLS connection over the migration data 549# channel. On the outgoing side of the migration, the credentials 550# must be for a 'client' endpoint, while for the incoming side the 551# credentials must be for a 'server' endpoint. Setting this 552# to a non-empty string enables TLS for all migrations. 553# An empty string means that QEMU will use plain text mode for 554# migration, rather than TLS (Since 2.9) 555# Previously (since 2.7), this was reported by omitting 556# tls-creds instead. 557# 558# @tls-hostname: hostname of the target host for the migration. This 559# is required when using x509 based TLS credentials and the 560# migration URI does not already include a hostname. For 561# example if using fd: or exec: based migration, the 562# hostname must be provided so that the server's x509 563# certificate identity can be validated. (Since 2.7) 564# An empty string means that QEMU will use the hostname 565# associated with the migration URI, if any. (Since 2.9) 566# Previously (since 2.7), this was reported by omitting 567# tls-hostname instead. 568# 569# @max-bandwidth: to set maximum speed for migration. maximum speed in 570# bytes per second. (Since 2.8) 571# 572# @downtime-limit: set maximum tolerated downtime for migration. maximum 573# downtime in milliseconds (Since 2.8) 574# 575# @x-checkpoint-delay: the delay time between two COLO checkpoints. (Since 2.8) 576# 577# @block-incremental: Affects how much storage is migrated when the 578# block migration capability is enabled. When false, the entire 579# storage backing chain is migrated into a flattened image at 580# the destination; when true, only the active qcow2 layer is 581# migrated and the destination must already have access to the 582# same backing chain as was used on the source. (since 2.10) 583# 584# @x-multifd-channels: Number of channels used to migrate data in 585# parallel. This is the same number that the 586# number of sockets used for migration. The 587# default value is 2 (since 2.11) 588# 589# @x-multifd-page-count: Number of pages sent together to a thread. 590# The default value is 16 (since 2.11) 591# 592# @xbzrle-cache-size: cache size to be used by XBZRLE migration. It 593# needs to be a multiple of the target page size 594# and a power of 2 595# (Since 2.11) 596# Since: 2.4 597## 598# TODO either fuse back into MigrationParameters, or make 599# MigrationParameters members mandatory 600{ 'struct': 'MigrateSetParameters', 601 'data': { '*compress-level': 'int', 602 '*compress-threads': 'int', 603 '*decompress-threads': 'int', 604 '*cpu-throttle-initial': 'int', 605 '*cpu-throttle-increment': 'int', 606 '*tls-creds': 'StrOrNull', 607 '*tls-hostname': 'StrOrNull', 608 '*max-bandwidth': 'int', 609 '*downtime-limit': 'int', 610 '*x-checkpoint-delay': 'int', 611 '*block-incremental': 'bool', 612 '*x-multifd-channels': 'int', 613 '*x-multifd-page-count': 'int', 614 '*xbzrle-cache-size': 'size' } } 615 616## 617# @migrate-set-parameters: 618# 619# Set various migration parameters. 620# 621# Since: 2.4 622# 623# Example: 624# 625# -> { "execute": "migrate-set-parameters" , 626# "arguments": { "compress-level": 1 } } 627# 628## 629{ 'command': 'migrate-set-parameters', 'boxed': true, 630 'data': 'MigrateSetParameters' } 631 632## 633# @MigrationParameters: 634# 635# The optional members aren't actually optional. 636# 637# @compress-level: compression level 638# 639# @compress-threads: compression thread count 640# 641# @decompress-threads: decompression thread count 642# 643# @cpu-throttle-initial: Initial percentage of time guest cpus are 644# throttled when migration auto-converge is activated. 645# (Since 2.7) 646# 647# @cpu-throttle-increment: throttle percentage increase each time 648# auto-converge detects that migration is not making 649# progress. (Since 2.7) 650# 651# @tls-creds: ID of the 'tls-creds' object that provides credentials 652# for establishing a TLS connection over the migration data 653# channel. On the outgoing side of the migration, the credentials 654# must be for a 'client' endpoint, while for the incoming side the 655# credentials must be for a 'server' endpoint. 656# An empty string means that QEMU will use plain text mode for 657# migration, rather than TLS (Since 2.7) 658# Note: 2.8 reports this by omitting tls-creds instead. 659# 660# @tls-hostname: hostname of the target host for the migration. This 661# is required when using x509 based TLS credentials and the 662# migration URI does not already include a hostname. For 663# example if using fd: or exec: based migration, the 664# hostname must be provided so that the server's x509 665# certificate identity can be validated. (Since 2.7) 666# An empty string means that QEMU will use the hostname 667# associated with the migration URI, if any. (Since 2.9) 668# Note: 2.8 reports this by omitting tls-hostname instead. 669# 670# @max-bandwidth: to set maximum speed for migration. maximum speed in 671# bytes per second. (Since 2.8) 672# 673# @downtime-limit: set maximum tolerated downtime for migration. maximum 674# downtime in milliseconds (Since 2.8) 675# 676# @x-checkpoint-delay: the delay time between two COLO checkpoints. (Since 2.8) 677# 678# @block-incremental: Affects how much storage is migrated when the 679# block migration capability is enabled. When false, the entire 680# storage backing chain is migrated into a flattened image at 681# the destination; when true, only the active qcow2 layer is 682# migrated and the destination must already have access to the 683# same backing chain as was used on the source. (since 2.10) 684# 685# @x-multifd-channels: Number of channels used to migrate data in 686# parallel. This is the same number that the 687# number of sockets used for migration. 688# The default value is 2 (since 2.11) 689# 690# @x-multifd-page-count: Number of pages sent together to a thread. 691# The default value is 16 (since 2.11) 692# 693# @xbzrle-cache-size: cache size to be used by XBZRLE migration. It 694# needs to be a multiple of the target page size 695# and a power of 2 696# (Since 2.11) 697# Since: 2.4 698## 699{ 'struct': 'MigrationParameters', 700 'data': { '*compress-level': 'uint8', 701 '*compress-threads': 'uint8', 702 '*decompress-threads': 'uint8', 703 '*cpu-throttle-initial': 'uint8', 704 '*cpu-throttle-increment': 'uint8', 705 '*tls-creds': 'str', 706 '*tls-hostname': 'str', 707 '*max-bandwidth': 'size', 708 '*downtime-limit': 'uint64', 709 '*x-checkpoint-delay': 'uint32', 710 '*block-incremental': 'bool' , 711 '*x-multifd-channels': 'uint8', 712 '*x-multifd-page-count': 'uint32', 713 '*xbzrle-cache-size': 'size' } } 714 715## 716# @query-migrate-parameters: 717# 718# Returns information about the current migration parameters 719# 720# Returns: @MigrationParameters 721# 722# Since: 2.4 723# 724# Example: 725# 726# -> { "execute": "query-migrate-parameters" } 727# <- { "return": { 728# "decompress-threads": 2, 729# "cpu-throttle-increment": 10, 730# "compress-threads": 8, 731# "compress-level": 1, 732# "cpu-throttle-initial": 20, 733# "max-bandwidth": 33554432, 734# "downtime-limit": 300 735# } 736# } 737# 738## 739{ 'command': 'query-migrate-parameters', 740 'returns': 'MigrationParameters' } 741 742## 743# @client_migrate_info: 744# 745# Set migration information for remote display. This makes the server 746# ask the client to automatically reconnect using the new parameters 747# once migration finished successfully. Only implemented for SPICE. 748# 749# @protocol: must be "spice" 750# @hostname: migration target hostname 751# @port: spice tcp port for plaintext channels 752# @tls-port: spice tcp port for tls-secured channels 753# @cert-subject: server certificate subject 754# 755# Since: 0.14.0 756# 757# Example: 758# 759# -> { "execute": "client_migrate_info", 760# "arguments": { "protocol": "spice", 761# "hostname": "virt42.lab.kraxel.org", 762# "port": 1234 } } 763# <- { "return": {} } 764# 765## 766{ 'command': 'client_migrate_info', 767 'data': { 'protocol': 'str', 'hostname': 'str', '*port': 'int', 768 '*tls-port': 'int', '*cert-subject': 'str' } } 769 770## 771# @migrate-start-postcopy: 772# 773# Followup to a migration command to switch the migration to postcopy mode. 774# The postcopy-ram capability must be set on both source and destination 775# before the original migration command. 776# 777# Since: 2.5 778# 779# Example: 780# 781# -> { "execute": "migrate-start-postcopy" } 782# <- { "return": {} } 783# 784## 785{ 'command': 'migrate-start-postcopy' } 786 787## 788# @MIGRATION: 789# 790# Emitted when a migration event happens 791# 792# @status: @MigrationStatus describing the current migration status. 793# 794# Since: 2.4 795# 796# Example: 797# 798# <- {"timestamp": {"seconds": 1432121972, "microseconds": 744001}, 799# "event": "MIGRATION", 800# "data": {"status": "completed"} } 801# 802## 803{ 'event': 'MIGRATION', 804 'data': {'status': 'MigrationStatus'}} 805 806## 807# @MIGRATION_PASS: 808# 809# Emitted from the source side of a migration at the start of each pass 810# (when it syncs the dirty bitmap) 811# 812# @pass: An incrementing count (starting at 1 on the first pass) 813# 814# Since: 2.6 815# 816# Example: 817# 818# { "timestamp": {"seconds": 1449669631, "microseconds": 239225}, 819# "event": "MIGRATION_PASS", "data": {"pass": 2} } 820# 821## 822{ 'event': 'MIGRATION_PASS', 823 'data': { 'pass': 'int' } } 824 825## 826# @COLOMessage: 827# 828# The message transmission between Primary side and Secondary side. 829# 830# @checkpoint-ready: Secondary VM (SVM) is ready for checkpointing 831# 832# @checkpoint-request: Primary VM (PVM) tells SVM to prepare for checkpointing 833# 834# @checkpoint-reply: SVM gets PVM's checkpoint request 835# 836# @vmstate-send: VM's state will be sent by PVM. 837# 838# @vmstate-size: The total size of VMstate. 839# 840# @vmstate-received: VM's state has been received by SVM. 841# 842# @vmstate-loaded: VM's state has been loaded by SVM. 843# 844# Since: 2.8 845## 846{ 'enum': 'COLOMessage', 847 'data': [ 'checkpoint-ready', 'checkpoint-request', 'checkpoint-reply', 848 'vmstate-send', 'vmstate-size', 'vmstate-received', 849 'vmstate-loaded' ] } 850 851## 852# @COLOMode: 853# 854# The colo mode 855# 856# @unknown: unknown mode 857# 858# @primary: master side 859# 860# @secondary: slave side 861# 862# Since: 2.8 863## 864{ 'enum': 'COLOMode', 865 'data': [ 'unknown', 'primary', 'secondary'] } 866 867## 868# @FailoverStatus: 869# 870# An enumeration of COLO failover status 871# 872# @none: no failover has ever happened 873# 874# @require: got failover requirement but not handled 875# 876# @active: in the process of doing failover 877# 878# @completed: finish the process of failover 879# 880# @relaunch: restart the failover process, from 'none' -> 'completed' (Since 2.9) 881# 882# Since: 2.8 883## 884{ 'enum': 'FailoverStatus', 885 'data': [ 'none', 'require', 'active', 'completed', 'relaunch' ] } 886 887## 888# @x-colo-lost-heartbeat: 889# 890# Tell qemu that heartbeat is lost, request it to do takeover procedures. 891# If this command is sent to the PVM, the Primary side will exit COLO mode. 892# If sent to the Secondary, the Secondary side will run failover work, 893# then takes over server operation to become the service VM. 894# 895# Since: 2.8 896# 897# Example: 898# 899# -> { "execute": "x-colo-lost-heartbeat" } 900# <- { "return": {} } 901# 902## 903{ 'command': 'x-colo-lost-heartbeat' } 904 905## 906# @migrate_cancel: 907# 908# Cancel the current executing migration process. 909# 910# Returns: nothing on success 911# 912# Notes: This command succeeds even if there is no migration process running. 913# 914# Since: 0.14.0 915# 916# Example: 917# 918# -> { "execute": "migrate_cancel" } 919# <- { "return": {} } 920# 921## 922{ 'command': 'migrate_cancel' } 923 924## 925# @migrate-continue: 926# 927# Continue migration when it's in a paused state. 928# 929# @state: The state the migration is currently expected to be in 930# 931# Returns: nothing on success 932# Since: 2.11 933# Example: 934# 935# -> { "execute": "migrate-continue" , "arguments": 936# { "state": "pre-switchover" } } 937# <- { "return": {} } 938## 939{ 'command': 'migrate-continue', 'data': {'state': 'MigrationStatus'} } 940 941## 942# @migrate_set_downtime: 943# 944# Set maximum tolerated downtime for migration. 945# 946# @value: maximum downtime in seconds 947# 948# Returns: nothing on success 949# 950# Notes: This command is deprecated in favor of 'migrate-set-parameters' 951# 952# Since: 0.14.0 953# 954# Example: 955# 956# -> { "execute": "migrate_set_downtime", "arguments": { "value": 0.1 } } 957# <- { "return": {} } 958# 959## 960{ 'command': 'migrate_set_downtime', 'data': {'value': 'number'} } 961 962## 963# @migrate_set_speed: 964# 965# Set maximum speed for migration. 966# 967# @value: maximum speed in bytes per second. 968# 969# Returns: nothing on success 970# 971# Notes: This command is deprecated in favor of 'migrate-set-parameters' 972# 973# Since: 0.14.0 974# 975# Example: 976# 977# -> { "execute": "migrate_set_speed", "arguments": { "value": 1024 } } 978# <- { "return": {} } 979# 980## 981{ 'command': 'migrate_set_speed', 'data': {'value': 'int'} } 982 983## 984# @migrate-set-cache-size: 985# 986# Set cache size to be used by XBZRLE migration 987# 988# @value: cache size in bytes 989# 990# The size will be rounded down to the nearest power of 2. 991# The cache size can be modified before and during ongoing migration 992# 993# Returns: nothing on success 994# 995# Notes: This command is deprecated in favor of 'migrate-set-parameters' 996# 997# Since: 1.2 998# 999# Example: 1000# 1001# -> { "execute": "migrate-set-cache-size", 1002# "arguments": { "value": 536870912 } } 1003# <- { "return": {} } 1004# 1005## 1006{ 'command': 'migrate-set-cache-size', 'data': {'value': 'int'} } 1007 1008## 1009# @query-migrate-cache-size: 1010# 1011# Query migration XBZRLE cache size 1012# 1013# Returns: XBZRLE cache size in bytes 1014# 1015# Notes: This command is deprecated in favor of 'query-migrate-parameters' 1016# 1017# Since: 1.2 1018# 1019# Example: 1020# 1021# -> { "execute": "query-migrate-cache-size" } 1022# <- { "return": 67108864 } 1023# 1024## 1025{ 'command': 'query-migrate-cache-size', 'returns': 'int' } 1026 1027## 1028# @migrate: 1029# 1030# Migrates the current running guest to another Virtual Machine. 1031# 1032# @uri: the Uniform Resource Identifier of the destination VM 1033# 1034# @blk: do block migration (full disk copy) 1035# 1036# @inc: incremental disk copy migration 1037# 1038# @detach: this argument exists only for compatibility reasons and 1039# is ignored by QEMU 1040# 1041# @resume: resume one paused migration, default "off". (since 3.0) 1042# 1043# Returns: nothing on success 1044# 1045# Since: 0.14.0 1046# 1047# Notes: 1048# 1049# 1. The 'query-migrate' command should be used to check migration's progress 1050# and final result (this information is provided by the 'status' member) 1051# 1052# 2. All boolean arguments default to false 1053# 1054# 3. The user Monitor's "detach" argument is invalid in QMP and should not 1055# be used 1056# 1057# Example: 1058# 1059# -> { "execute": "migrate", "arguments": { "uri": "tcp:0:4446" } } 1060# <- { "return": {} } 1061# 1062## 1063{ 'command': 'migrate', 1064 'data': {'uri': 'str', '*blk': 'bool', '*inc': 'bool', 1065 '*detach': 'bool', '*resume': 'bool' } } 1066 1067## 1068# @migrate-incoming: 1069# 1070# Start an incoming migration, the qemu must have been started 1071# with -incoming defer 1072# 1073# @uri: The Uniform Resource Identifier identifying the source or 1074# address to listen on 1075# 1076# Returns: nothing on success 1077# 1078# Since: 2.3 1079# 1080# Notes: 1081# 1082# 1. It's a bad idea to use a string for the uri, but it needs to stay 1083# compatible with -incoming and the format of the uri is already exposed 1084# above libvirt. 1085# 1086# 2. QEMU must be started with -incoming defer to allow migrate-incoming to 1087# be used. 1088# 1089# 3. The uri format is the same as for -incoming 1090# 1091# Example: 1092# 1093# -> { "execute": "migrate-incoming", 1094# "arguments": { "uri": "tcp::4446" } } 1095# <- { "return": {} } 1096# 1097## 1098{ 'command': 'migrate-incoming', 'data': {'uri': 'str' } } 1099 1100## 1101# @xen-save-devices-state: 1102# 1103# Save the state of all devices to file. The RAM and the block devices 1104# of the VM are not saved by this command. 1105# 1106# @filename: the file to save the state of the devices to as binary 1107# data. See xen-save-devices-state.txt for a description of the binary 1108# format. 1109# 1110# @live: Optional argument to ask QEMU to treat this command as part of a live 1111# migration. Default to true. (since 2.11) 1112# 1113# Returns: Nothing on success 1114# 1115# Since: 1.1 1116# 1117# Example: 1118# 1119# -> { "execute": "xen-save-devices-state", 1120# "arguments": { "filename": "/tmp/save" } } 1121# <- { "return": {} } 1122# 1123## 1124{ 'command': 'xen-save-devices-state', 1125 'data': {'filename': 'str', '*live':'bool' } } 1126 1127## 1128# @xen-set-replication: 1129# 1130# Enable or disable replication. 1131# 1132# @enable: true to enable, false to disable. 1133# 1134# @primary: true for primary or false for secondary. 1135# 1136# @failover: true to do failover, false to stop. but cannot be 1137# specified if 'enable' is true. default value is false. 1138# 1139# Returns: nothing. 1140# 1141# Example: 1142# 1143# -> { "execute": "xen-set-replication", 1144# "arguments": {"enable": true, "primary": false} } 1145# <- { "return": {} } 1146# 1147# Since: 2.9 1148## 1149{ 'command': 'xen-set-replication', 1150 'data': { 'enable': 'bool', 'primary': 'bool', '*failover' : 'bool' } } 1151 1152## 1153# @ReplicationStatus: 1154# 1155# The result format for 'query-xen-replication-status'. 1156# 1157# @error: true if an error happened, false if replication is normal. 1158# 1159# @desc: the human readable error description string, when 1160# @error is 'true'. 1161# 1162# Since: 2.9 1163## 1164{ 'struct': 'ReplicationStatus', 1165 'data': { 'error': 'bool', '*desc': 'str' } } 1166 1167## 1168# @query-xen-replication-status: 1169# 1170# Query replication status while the vm is running. 1171# 1172# Returns: A @ReplicationResult object showing the status. 1173# 1174# Example: 1175# 1176# -> { "execute": "query-xen-replication-status" } 1177# <- { "return": { "error": false } } 1178# 1179# Since: 2.9 1180## 1181{ 'command': 'query-xen-replication-status', 1182 'returns': 'ReplicationStatus' } 1183 1184## 1185# @xen-colo-do-checkpoint: 1186# 1187# Xen uses this command to notify replication to trigger a checkpoint. 1188# 1189# Returns: nothing. 1190# 1191# Example: 1192# 1193# -> { "execute": "xen-colo-do-checkpoint" } 1194# <- { "return": {} } 1195# 1196# Since: 2.9 1197## 1198{ 'command': 'xen-colo-do-checkpoint' } 1199 1200## 1201# @migrate-recover: 1202# 1203# Provide a recovery migration stream URI. 1204# 1205# @uri: the URI to be used for the recovery of migration stream. 1206# 1207# Returns: nothing. 1208# 1209# Example: 1210# 1211# -> { "execute": "migrate-recover", 1212# "arguments": { "uri": "tcp:192.168.1.200:12345" } } 1213# <- { "return": {} } 1214# 1215# Since: 3.0 1216## 1217{ 'command': 'migrate-recover', 'data': { 'uri': 'str' }, 1218 'allow-oob': true } 1219 1220## 1221# @migrate-pause: 1222# 1223# Pause a migration. Currently it only supports postcopy. 1224# 1225# Returns: nothing. 1226# 1227# Example: 1228# 1229# -> { "execute": "migrate-pause" } 1230# <- { "return": {} } 1231# 1232# Since: 3.0 1233## 1234{ 'command': 'migrate-pause', 'allow-oob': true } 1235