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# @dirty-bitmaps: If enabled, QEMU will migrate named dirty bitmaps. 358# (since 2.12) 359# 360# Since: 1.2 361## 362{ 'enum': 'MigrationCapability', 363 'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks', 364 'compress', 'events', 'postcopy-ram', 'x-colo', 'release-ram', 365 'block', 'return-path', 'pause-before-switchover', 'x-multifd', 366 'dirty-bitmaps' ] } 367 368## 369# @MigrationCapabilityStatus: 370# 371# Migration capability information 372# 373# @capability: capability enum 374# 375# @state: capability state bool 376# 377# Since: 1.2 378## 379{ 'struct': 'MigrationCapabilityStatus', 380 'data': { 'capability' : 'MigrationCapability', 'state' : 'bool' } } 381 382## 383# @migrate-set-capabilities: 384# 385# Enable/Disable the following migration capabilities (like xbzrle) 386# 387# @capabilities: json array of capability modifications to make 388# 389# Since: 1.2 390# 391# Example: 392# 393# -> { "execute": "migrate-set-capabilities" , "arguments": 394# { "capabilities": [ { "capability": "xbzrle", "state": true } ] } } 395# 396## 397{ 'command': 'migrate-set-capabilities', 398 'data': { 'capabilities': ['MigrationCapabilityStatus'] } } 399 400## 401# @query-migrate-capabilities: 402# 403# Returns information about the current migration capabilities status 404# 405# Returns: @MigrationCapabilitiesStatus 406# 407# Since: 1.2 408# 409# Example: 410# 411# -> { "execute": "query-migrate-capabilities" } 412# <- { "return": [ 413# {"state": false, "capability": "xbzrle"}, 414# {"state": false, "capability": "rdma-pin-all"}, 415# {"state": false, "capability": "auto-converge"}, 416# {"state": false, "capability": "zero-blocks"}, 417# {"state": false, "capability": "compress"}, 418# {"state": true, "capability": "events"}, 419# {"state": false, "capability": "postcopy-ram"}, 420# {"state": false, "capability": "x-colo"} 421# ]} 422# 423## 424{ 'command': 'query-migrate-capabilities', 'returns': ['MigrationCapabilityStatus']} 425 426## 427# @MigrationParameter: 428# 429# Migration parameters enumeration 430# 431# @compress-level: Set the compression level to be used in live migration, 432# the compression level is an integer between 0 and 9, where 0 means 433# no compression, 1 means the best compression speed, and 9 means best 434# compression ratio which will consume more CPU. 435# 436# @compress-threads: Set compression thread count to be used in live migration, 437# the compression thread count is an integer between 1 and 255. 438# 439# @decompress-threads: Set decompression thread count to be used in live 440# migration, the decompression thread count is an integer between 1 441# and 255. Usually, decompression is at least 4 times as fast as 442# compression, so set the decompress-threads to the number about 1/4 443# of compress-threads is adequate. 444# 445# @cpu-throttle-initial: Initial percentage of time guest cpus are throttled 446# when migration auto-converge is activated. The 447# default value is 20. (Since 2.7) 448# 449# @cpu-throttle-increment: throttle percentage increase each time 450# auto-converge detects that migration is not making 451# progress. The default value is 10. (Since 2.7) 452# 453# @tls-creds: ID of the 'tls-creds' object that provides credentials for 454# establishing a TLS connection over the migration data channel. 455# On the outgoing side of the migration, the credentials must 456# be for a 'client' endpoint, while for the incoming side the 457# credentials must be for a 'server' endpoint. Setting this 458# will enable TLS for all migrations. The default is unset, 459# resulting in unsecured migration at the QEMU level. (Since 2.7) 460# 461# @tls-hostname: hostname of the target host for the migration. This is 462# required when using x509 based TLS credentials and the 463# migration URI does not already include a hostname. For 464# example if using fd: or exec: based migration, the 465# hostname must be provided so that the server's x509 466# certificate identity can be validated. (Since 2.7) 467# 468# @max-bandwidth: to set maximum speed for migration. maximum speed in 469# bytes per second. (Since 2.8) 470# 471# @downtime-limit: set maximum tolerated downtime for migration. maximum 472# downtime in milliseconds (Since 2.8) 473# 474# @x-checkpoint-delay: The delay time (in ms) between two COLO checkpoints in 475# periodic mode. (Since 2.8) 476# 477# @block-incremental: Affects how much storage is migrated when the 478# block migration capability is enabled. When false, the entire 479# storage backing chain is migrated into a flattened image at 480# the destination; when true, only the active qcow2 layer is 481# migrated and the destination must already have access to the 482# same backing chain as was used on the source. (since 2.10) 483# 484# @x-multifd-channels: Number of channels used to migrate data in 485# parallel. This is the same number that the 486# number of sockets used for migration. The 487# default value is 2 (since 2.11) 488# 489# @x-multifd-page-count: Number of pages sent together to a thread. 490# The default value is 16 (since 2.11) 491# 492# @xbzrle-cache-size: cache size to be used by XBZRLE migration. It 493# needs to be a multiple of the target page size 494# and a power of 2 495# (Since 2.11) 496# 497# Since: 2.4 498## 499{ 'enum': 'MigrationParameter', 500 'data': ['compress-level', 'compress-threads', 'decompress-threads', 501 'cpu-throttle-initial', 'cpu-throttle-increment', 502 'tls-creds', 'tls-hostname', 'max-bandwidth', 503 'downtime-limit', 'x-checkpoint-delay', 'block-incremental', 504 'x-multifd-channels', 'x-multifd-page-count', 505 'xbzrle-cache-size' ] } 506 507## 508# @MigrateSetParameters: 509# 510# @compress-level: compression level 511# 512# @compress-threads: compression thread count 513# 514# @decompress-threads: decompression thread count 515# 516# @cpu-throttle-initial: Initial percentage of time guest cpus are 517# throttled when migration auto-converge is activated. 518# The default value is 20. (Since 2.7) 519# 520# @cpu-throttle-increment: throttle percentage increase each time 521# auto-converge detects that migration is not making 522# progress. The default value is 10. (Since 2.7) 523# 524# @tls-creds: ID of the 'tls-creds' object that provides credentials 525# for establishing a TLS connection over the migration data 526# channel. On the outgoing side of the migration, the credentials 527# must be for a 'client' endpoint, while for the incoming side the 528# credentials must be for a 'server' endpoint. Setting this 529# to a non-empty string enables TLS for all migrations. 530# An empty string means that QEMU will use plain text mode for 531# migration, rather than TLS (Since 2.9) 532# Previously (since 2.7), this was reported by omitting 533# tls-creds instead. 534# 535# @tls-hostname: hostname of the target host for the migration. This 536# is required when using x509 based TLS credentials and the 537# migration URI does not already include a hostname. For 538# example if using fd: or exec: based migration, the 539# hostname must be provided so that the server's x509 540# certificate identity can be validated. (Since 2.7) 541# An empty string means that QEMU will use the hostname 542# associated with the migration URI, if any. (Since 2.9) 543# Previously (since 2.7), this was reported by omitting 544# tls-hostname instead. 545# 546# @max-bandwidth: to set maximum speed for migration. maximum speed in 547# bytes per second. (Since 2.8) 548# 549# @downtime-limit: set maximum tolerated downtime for migration. maximum 550# downtime in milliseconds (Since 2.8) 551# 552# @x-checkpoint-delay: the delay time between two COLO checkpoints. (Since 2.8) 553# 554# @block-incremental: Affects how much storage is migrated when the 555# block migration capability is enabled. When false, the entire 556# storage backing chain is migrated into a flattened image at 557# the destination; when true, only the active qcow2 layer is 558# migrated and the destination must already have access to the 559# same backing chain as was used on the source. (since 2.10) 560# 561# @x-multifd-channels: Number of channels used to migrate data in 562# parallel. This is the same number that the 563# number of sockets used for migration. The 564# default value is 2 (since 2.11) 565# 566# @x-multifd-page-count: Number of pages sent together to a thread. 567# The default value is 16 (since 2.11) 568# 569# @xbzrle-cache-size: cache size to be used by XBZRLE migration. It 570# needs to be a multiple of the target page size 571# and a power of 2 572# (Since 2.11) 573# Since: 2.4 574## 575# TODO either fuse back into MigrationParameters, or make 576# MigrationParameters members mandatory 577{ 'struct': 'MigrateSetParameters', 578 'data': { '*compress-level': 'int', 579 '*compress-threads': 'int', 580 '*decompress-threads': 'int', 581 '*cpu-throttle-initial': 'int', 582 '*cpu-throttle-increment': 'int', 583 '*tls-creds': 'StrOrNull', 584 '*tls-hostname': 'StrOrNull', 585 '*max-bandwidth': 'int', 586 '*downtime-limit': 'int', 587 '*x-checkpoint-delay': 'int', 588 '*block-incremental': 'bool', 589 '*x-multifd-channels': 'int', 590 '*x-multifd-page-count': 'int', 591 '*xbzrle-cache-size': 'size' } } 592 593## 594# @migrate-set-parameters: 595# 596# Set various migration parameters. 597# 598# Since: 2.4 599# 600# Example: 601# 602# -> { "execute": "migrate-set-parameters" , 603# "arguments": { "compress-level": 1 } } 604# 605## 606{ 'command': 'migrate-set-parameters', 'boxed': true, 607 'data': 'MigrateSetParameters' } 608 609## 610# @MigrationParameters: 611# 612# The optional members aren't actually optional. 613# 614# @compress-level: compression level 615# 616# @compress-threads: compression thread count 617# 618# @decompress-threads: decompression thread count 619# 620# @cpu-throttle-initial: Initial percentage of time guest cpus are 621# throttled when migration auto-converge is activated. 622# (Since 2.7) 623# 624# @cpu-throttle-increment: throttle percentage increase each time 625# auto-converge detects that migration is not making 626# progress. (Since 2.7) 627# 628# @tls-creds: ID of the 'tls-creds' object that provides credentials 629# for establishing a TLS connection over the migration data 630# channel. On the outgoing side of the migration, the credentials 631# must be for a 'client' endpoint, while for the incoming side the 632# credentials must be for a 'server' endpoint. 633# An empty string means that QEMU will use plain text mode for 634# migration, rather than TLS (Since 2.7) 635# Note: 2.8 reports this by omitting tls-creds instead. 636# 637# @tls-hostname: hostname of the target host for the migration. This 638# is required when using x509 based TLS credentials and the 639# migration URI does not already include a hostname. For 640# example if using fd: or exec: based migration, the 641# hostname must be provided so that the server's x509 642# certificate identity can be validated. (Since 2.7) 643# An empty string means that QEMU will use the hostname 644# associated with the migration URI, if any. (Since 2.9) 645# Note: 2.8 reports this by omitting tls-hostname instead. 646# 647# @max-bandwidth: to set maximum speed for migration. maximum speed in 648# bytes per second. (Since 2.8) 649# 650# @downtime-limit: set maximum tolerated downtime for migration. maximum 651# downtime in milliseconds (Since 2.8) 652# 653# @x-checkpoint-delay: the delay time between two COLO checkpoints. (Since 2.8) 654# 655# @block-incremental: Affects how much storage is migrated when the 656# block migration capability is enabled. When false, the entire 657# storage backing chain is migrated into a flattened image at 658# the destination; when true, only the active qcow2 layer is 659# migrated and the destination must already have access to the 660# same backing chain as was used on the source. (since 2.10) 661# 662# @x-multifd-channels: Number of channels used to migrate data in 663# parallel. This is the same number that the 664# number of sockets used for migration. 665# The default value is 2 (since 2.11) 666# 667# @x-multifd-page-count: Number of pages sent together to a thread. 668# The default value is 16 (since 2.11) 669# 670# @xbzrle-cache-size: cache size to be used by XBZRLE migration. It 671# needs to be a multiple of the target page size 672# and a power of 2 673# (Since 2.11) 674# Since: 2.4 675## 676{ 'struct': 'MigrationParameters', 677 'data': { '*compress-level': 'uint8', 678 '*compress-threads': 'uint8', 679 '*decompress-threads': 'uint8', 680 '*cpu-throttle-initial': 'uint8', 681 '*cpu-throttle-increment': 'uint8', 682 '*tls-creds': 'str', 683 '*tls-hostname': 'str', 684 '*max-bandwidth': 'size', 685 '*downtime-limit': 'uint64', 686 '*x-checkpoint-delay': 'uint32', 687 '*block-incremental': 'bool' , 688 '*x-multifd-channels': 'uint8', 689 '*x-multifd-page-count': 'uint32', 690 '*xbzrle-cache-size': 'size' } } 691 692## 693# @query-migrate-parameters: 694# 695# Returns information about the current migration parameters 696# 697# Returns: @MigrationParameters 698# 699# Since: 2.4 700# 701# Example: 702# 703# -> { "execute": "query-migrate-parameters" } 704# <- { "return": { 705# "decompress-threads": 2, 706# "cpu-throttle-increment": 10, 707# "compress-threads": 8, 708# "compress-level": 1, 709# "cpu-throttle-initial": 20, 710# "max-bandwidth": 33554432, 711# "downtime-limit": 300 712# } 713# } 714# 715## 716{ 'command': 'query-migrate-parameters', 717 'returns': 'MigrationParameters' } 718 719## 720# @client_migrate_info: 721# 722# Set migration information for remote display. This makes the server 723# ask the client to automatically reconnect using the new parameters 724# once migration finished successfully. Only implemented for SPICE. 725# 726# @protocol: must be "spice" 727# @hostname: migration target hostname 728# @port: spice tcp port for plaintext channels 729# @tls-port: spice tcp port for tls-secured channels 730# @cert-subject: server certificate subject 731# 732# Since: 0.14.0 733# 734# Example: 735# 736# -> { "execute": "client_migrate_info", 737# "arguments": { "protocol": "spice", 738# "hostname": "virt42.lab.kraxel.org", 739# "port": 1234 } } 740# <- { "return": {} } 741# 742## 743{ 'command': 'client_migrate_info', 744 'data': { 'protocol': 'str', 'hostname': 'str', '*port': 'int', 745 '*tls-port': 'int', '*cert-subject': 'str' } } 746 747## 748# @migrate-start-postcopy: 749# 750# Followup to a migration command to switch the migration to postcopy mode. 751# The postcopy-ram capability must be set on both source and destination 752# before the original migration command. 753# 754# Since: 2.5 755# 756# Example: 757# 758# -> { "execute": "migrate-start-postcopy" } 759# <- { "return": {} } 760# 761## 762{ 'command': 'migrate-start-postcopy' } 763 764## 765# @MIGRATION: 766# 767# Emitted when a migration event happens 768# 769# @status: @MigrationStatus describing the current migration status. 770# 771# Since: 2.4 772# 773# Example: 774# 775# <- {"timestamp": {"seconds": 1432121972, "microseconds": 744001}, 776# "event": "MIGRATION", 777# "data": {"status": "completed"} } 778# 779## 780{ 'event': 'MIGRATION', 781 'data': {'status': 'MigrationStatus'}} 782 783## 784# @MIGRATION_PASS: 785# 786# Emitted from the source side of a migration at the start of each pass 787# (when it syncs the dirty bitmap) 788# 789# @pass: An incrementing count (starting at 1 on the first pass) 790# 791# Since: 2.6 792# 793# Example: 794# 795# { "timestamp": {"seconds": 1449669631, "microseconds": 239225}, 796# "event": "MIGRATION_PASS", "data": {"pass": 2} } 797# 798## 799{ 'event': 'MIGRATION_PASS', 800 'data': { 'pass': 'int' } } 801 802## 803# @COLOMessage: 804# 805# The message transmission between Primary side and Secondary side. 806# 807# @checkpoint-ready: Secondary VM (SVM) is ready for checkpointing 808# 809# @checkpoint-request: Primary VM (PVM) tells SVM to prepare for checkpointing 810# 811# @checkpoint-reply: SVM gets PVM's checkpoint request 812# 813# @vmstate-send: VM's state will be sent by PVM. 814# 815# @vmstate-size: The total size of VMstate. 816# 817# @vmstate-received: VM's state has been received by SVM. 818# 819# @vmstate-loaded: VM's state has been loaded by SVM. 820# 821# Since: 2.8 822## 823{ 'enum': 'COLOMessage', 824 'data': [ 'checkpoint-ready', 'checkpoint-request', 'checkpoint-reply', 825 'vmstate-send', 'vmstate-size', 'vmstate-received', 826 'vmstate-loaded' ] } 827 828## 829# @COLOMode: 830# 831# The colo mode 832# 833# @unknown: unknown mode 834# 835# @primary: master side 836# 837# @secondary: slave side 838# 839# Since: 2.8 840## 841{ 'enum': 'COLOMode', 842 'data': [ 'unknown', 'primary', 'secondary'] } 843 844## 845# @FailoverStatus: 846# 847# An enumeration of COLO failover status 848# 849# @none: no failover has ever happened 850# 851# @require: got failover requirement but not handled 852# 853# @active: in the process of doing failover 854# 855# @completed: finish the process of failover 856# 857# @relaunch: restart the failover process, from 'none' -> 'completed' (Since 2.9) 858# 859# Since: 2.8 860## 861{ 'enum': 'FailoverStatus', 862 'data': [ 'none', 'require', 'active', 'completed', 'relaunch' ] } 863 864## 865# @x-colo-lost-heartbeat: 866# 867# Tell qemu that heartbeat is lost, request it to do takeover procedures. 868# If this command is sent to the PVM, the Primary side will exit COLO mode. 869# If sent to the Secondary, the Secondary side will run failover work, 870# then takes over server operation to become the service VM. 871# 872# Since: 2.8 873# 874# Example: 875# 876# -> { "execute": "x-colo-lost-heartbeat" } 877# <- { "return": {} } 878# 879## 880{ 'command': 'x-colo-lost-heartbeat' } 881 882## 883# @migrate_cancel: 884# 885# Cancel the current executing migration process. 886# 887# Returns: nothing on success 888# 889# Notes: This command succeeds even if there is no migration process running. 890# 891# Since: 0.14.0 892# 893# Example: 894# 895# -> { "execute": "migrate_cancel" } 896# <- { "return": {} } 897# 898## 899{ 'command': 'migrate_cancel' } 900 901## 902# @migrate-continue: 903# 904# Continue migration when it's in a paused state. 905# 906# @state: The state the migration is currently expected to be in 907# 908# Returns: nothing on success 909# Since: 2.11 910# Example: 911# 912# -> { "execute": "migrate-continue" , "arguments": 913# { "state": "pre-switchover" } } 914# <- { "return": {} } 915## 916{ 'command': 'migrate-continue', 'data': {'state': 'MigrationStatus'} } 917 918## 919# @migrate_set_downtime: 920# 921# Set maximum tolerated downtime for migration. 922# 923# @value: maximum downtime in seconds 924# 925# Returns: nothing on success 926# 927# Notes: This command is deprecated in favor of 'migrate-set-parameters' 928# 929# Since: 0.14.0 930# 931# Example: 932# 933# -> { "execute": "migrate_set_downtime", "arguments": { "value": 0.1 } } 934# <- { "return": {} } 935# 936## 937{ 'command': 'migrate_set_downtime', 'data': {'value': 'number'} } 938 939## 940# @migrate_set_speed: 941# 942# Set maximum speed for migration. 943# 944# @value: maximum speed in bytes per second. 945# 946# Returns: nothing on success 947# 948# Notes: This command is deprecated in favor of 'migrate-set-parameters' 949# 950# Since: 0.14.0 951# 952# Example: 953# 954# -> { "execute": "migrate_set_speed", "arguments": { "value": 1024 } } 955# <- { "return": {} } 956# 957## 958{ 'command': 'migrate_set_speed', 'data': {'value': 'int'} } 959 960## 961# @migrate-set-cache-size: 962# 963# Set cache size to be used by XBZRLE migration 964# 965# @value: cache size in bytes 966# 967# The size will be rounded down to the nearest power of 2. 968# The cache size can be modified before and during ongoing migration 969# 970# Returns: nothing on success 971# 972# Notes: This command is deprecated in favor of 'migrate-set-parameters' 973# 974# Since: 1.2 975# 976# Example: 977# 978# -> { "execute": "migrate-set-cache-size", 979# "arguments": { "value": 536870912 } } 980# <- { "return": {} } 981# 982## 983{ 'command': 'migrate-set-cache-size', 'data': {'value': 'int'} } 984 985## 986# @query-migrate-cache-size: 987# 988# Query migration XBZRLE cache size 989# 990# Returns: XBZRLE cache size in bytes 991# 992# Notes: This command is deprecated in favor of 'query-migrate-parameters' 993# 994# Since: 1.2 995# 996# Example: 997# 998# -> { "execute": "query-migrate-cache-size" } 999# <- { "return": 67108864 } 1000# 1001## 1002{ 'command': 'query-migrate-cache-size', 'returns': 'int' } 1003 1004## 1005# @migrate: 1006# 1007# Migrates the current running guest to another Virtual Machine. 1008# 1009# @uri: the Uniform Resource Identifier of the destination VM 1010# 1011# @blk: do block migration (full disk copy) 1012# 1013# @inc: incremental disk copy migration 1014# 1015# @detach: this argument exists only for compatibility reasons and 1016# is ignored by QEMU 1017# 1018# Returns: nothing on success 1019# 1020# Since: 0.14.0 1021# 1022# Notes: 1023# 1024# 1. The 'query-migrate' command should be used to check migration's progress 1025# and final result (this information is provided by the 'status' member) 1026# 1027# 2. All boolean arguments default to false 1028# 1029# 3. The user Monitor's "detach" argument is invalid in QMP and should not 1030# be used 1031# 1032# Example: 1033# 1034# -> { "execute": "migrate", "arguments": { "uri": "tcp:0:4446" } } 1035# <- { "return": {} } 1036# 1037## 1038{ 'command': 'migrate', 1039 'data': {'uri': 'str', '*blk': 'bool', '*inc': 'bool', '*detach': 'bool' } } 1040 1041## 1042# @migrate-incoming: 1043# 1044# Start an incoming migration, the qemu must have been started 1045# with -incoming defer 1046# 1047# @uri: The Uniform Resource Identifier identifying the source or 1048# address to listen on 1049# 1050# Returns: nothing on success 1051# 1052# Since: 2.3 1053# 1054# Notes: 1055# 1056# 1. It's a bad idea to use a string for the uri, but it needs to stay 1057# compatible with -incoming and the format of the uri is already exposed 1058# above libvirt. 1059# 1060# 2. QEMU must be started with -incoming defer to allow migrate-incoming to 1061# be used. 1062# 1063# 3. The uri format is the same as for -incoming 1064# 1065# Example: 1066# 1067# -> { "execute": "migrate-incoming", 1068# "arguments": { "uri": "tcp::4446" } } 1069# <- { "return": {} } 1070# 1071## 1072{ 'command': 'migrate-incoming', 'data': {'uri': 'str' } } 1073 1074## 1075# @xen-save-devices-state: 1076# 1077# Save the state of all devices to file. The RAM and the block devices 1078# of the VM are not saved by this command. 1079# 1080# @filename: the file to save the state of the devices to as binary 1081# data. See xen-save-devices-state.txt for a description of the binary 1082# format. 1083# 1084# @live: Optional argument to ask QEMU to treat this command as part of a live 1085# migration. Default to true. (since 2.11) 1086# 1087# Returns: Nothing on success 1088# 1089# Since: 1.1 1090# 1091# Example: 1092# 1093# -> { "execute": "xen-save-devices-state", 1094# "arguments": { "filename": "/tmp/save" } } 1095# <- { "return": {} } 1096# 1097## 1098{ 'command': 'xen-save-devices-state', 1099 'data': {'filename': 'str', '*live':'bool' } } 1100 1101## 1102# @xen-set-replication: 1103# 1104# Enable or disable replication. 1105# 1106# @enable: true to enable, false to disable. 1107# 1108# @primary: true for primary or false for secondary. 1109# 1110# @failover: true to do failover, false to stop. but cannot be 1111# specified if 'enable' is true. default value is false. 1112# 1113# Returns: nothing. 1114# 1115# Example: 1116# 1117# -> { "execute": "xen-set-replication", 1118# "arguments": {"enable": true, "primary": false} } 1119# <- { "return": {} } 1120# 1121# Since: 2.9 1122## 1123{ 'command': 'xen-set-replication', 1124 'data': { 'enable': 'bool', 'primary': 'bool', '*failover' : 'bool' } } 1125 1126## 1127# @ReplicationStatus: 1128# 1129# The result format for 'query-xen-replication-status'. 1130# 1131# @error: true if an error happened, false if replication is normal. 1132# 1133# @desc: the human readable error description string, when 1134# @error is 'true'. 1135# 1136# Since: 2.9 1137## 1138{ 'struct': 'ReplicationStatus', 1139 'data': { 'error': 'bool', '*desc': 'str' } } 1140 1141## 1142# @query-xen-replication-status: 1143# 1144# Query replication status while the vm is running. 1145# 1146# Returns: A @ReplicationResult object showing the status. 1147# 1148# Example: 1149# 1150# -> { "execute": "query-xen-replication-status" } 1151# <- { "return": { "error": false } } 1152# 1153# Since: 2.9 1154## 1155{ 'command': 'query-xen-replication-status', 1156 'returns': 'ReplicationStatus' } 1157 1158## 1159# @xen-colo-do-checkpoint: 1160# 1161# Xen uses this command to notify replication to trigger a checkpoint. 1162# 1163# Returns: nothing. 1164# 1165# Example: 1166# 1167# -> { "execute": "xen-colo-do-checkpoint" } 1168# <- { "return": {} } 1169# 1170# Since: 2.9 1171## 1172{ 'command': 'xen-colo-do-checkpoint' } 1173