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