1========= 2Migration 3========= 4 5QEMU has code to load/save the state of the guest that it is running. 6These are two complementary operations. Saving the state just does 7that, saves the state for each device that the guest is running. 8Restoring a guest is just the opposite operation: we need to load the 9state of each device. 10 11For this to work, QEMU has to be launched with the same arguments the 12two times. I.e. it can only restore the state in one guest that has 13the same devices that the one it was saved (this last requirement can 14be relaxed a bit, but for now we can consider that configuration has 15to be exactly the same). 16 17Once that we are able to save/restore a guest, a new functionality is 18requested: migration. This means that QEMU is able to start in one 19machine and being "migrated" to another machine. I.e. being moved to 20another machine. 21 22Next was the "live migration" functionality. This is important 23because some guests run with a lot of state (specially RAM), and it 24can take a while to move all state from one machine to another. Live 25migration allows the guest to continue running while the state is 26transferred. Only while the last part of the state is transferred has 27the guest to be stopped. Typically the time that the guest is 28unresponsive during live migration is the low hundred of milliseconds 29(notice that this depends on a lot of things). 30 31Transports 32========== 33 34The migration stream is normally just a byte stream that can be passed 35over any transport. 36 37- tcp migration: do the migration using tcp sockets 38- unix migration: do the migration using unix sockets 39- exec migration: do the migration using the stdin/stdout through a process. 40- fd migration: do the migration using a file descriptor that is 41 passed to QEMU. QEMU doesn't care how this file descriptor is opened. 42 43In addition, support is included for migration using RDMA, which 44transports the page data using ``RDMA``, where the hardware takes care of 45transporting the pages, and the load on the CPU is much lower. While the 46internals of RDMA migration are a bit different, this isn't really visible 47outside the RAM migration code. 48 49All these migration protocols use the same infrastructure to 50save/restore state devices. This infrastructure is shared with the 51savevm/loadvm functionality. 52 53Debugging 54========= 55 56The migration stream can be analyzed thanks to ``scripts/analyze-migration.py``. 57 58Example usage: 59 60.. code-block:: shell 61 62 $ qemu-system-x86_64 -display none -monitor stdio 63 (qemu) migrate "exec:cat > mig" 64 (qemu) q 65 $ ./scripts/analyze-migration.py -f mig 66 { 67 "ram (3)": { 68 "section sizes": { 69 "pc.ram": "0x0000000008000000", 70 ... 71 72See also ``analyze-migration.py -h`` help for more options. 73 74Common infrastructure 75===================== 76 77The files, sockets or fd's that carry the migration stream are abstracted by 78the ``QEMUFile`` type (see ``migration/qemu-file.h``). In most cases this 79is connected to a subtype of ``QIOChannel`` (see ``io/``). 80 81 82Saving the state of one device 83============================== 84 85For most devices, the state is saved in a single call to the migration 86infrastructure; these are *non-iterative* devices. The data for these 87devices is sent at the end of precopy migration, when the CPUs are paused. 88There are also *iterative* devices, which contain a very large amount of 89data (e.g. RAM or large tables). See the iterative device section below. 90 91General advice for device developers 92------------------------------------ 93 94- The migration state saved should reflect the device being modelled rather 95 than the way your implementation works. That way if you change the implementation 96 later the migration stream will stay compatible. That model may include 97 internal state that's not directly visible in a register. 98 99- When saving a migration stream the device code may walk and check 100 the state of the device. These checks might fail in various ways (e.g. 101 discovering internal state is corrupt or that the guest has done something bad). 102 Consider carefully before asserting/aborting at this point, since the 103 normal response from users is that *migration broke their VM* since it had 104 apparently been running fine until then. In these error cases, the device 105 should log a message indicating the cause of error, and should consider 106 putting the device into an error state, allowing the rest of the VM to 107 continue execution. 108 109- The migration might happen at an inconvenient point, 110 e.g. right in the middle of the guest reprogramming the device, during 111 guest reboot or shutdown or while the device is waiting for external IO. 112 It's strongly preferred that migrations do not fail in this situation, 113 since in the cloud environment migrations might happen automatically to 114 VMs that the administrator doesn't directly control. 115 116- If you do need to fail a migration, ensure that sufficient information 117 is logged to identify what went wrong. 118 119- The destination should treat an incoming migration stream as hostile 120 (which we do to varying degrees in the existing code). Check that offsets 121 into buffers and the like can't cause overruns. Fail the incoming migration 122 in the case of a corrupted stream like this. 123 124- Take care with internal device state or behaviour that might become 125 migration version dependent. For example, the order of PCI capabilities 126 is required to stay constant across migration. Another example would 127 be that a special case handled by subsections (see below) might become 128 much more common if a default behaviour is changed. 129 130- The state of the source should not be changed or destroyed by the 131 outgoing migration. Migrations timing out or being failed by 132 higher levels of management, or failures of the destination host are 133 not unusual, and in that case the VM is restarted on the source. 134 Note that the management layer can validly revert the migration 135 even though the QEMU level of migration has succeeded as long as it 136 does it before starting execution on the destination. 137 138- Buses and devices should be able to explicitly specify addresses when 139 instantiated, and management tools should use those. For example, 140 when hot adding USB devices it's important to specify the ports 141 and addresses, since implicit ordering based on the command line order 142 may be different on the destination. This can result in the 143 device state being loaded into the wrong device. 144 145VMState 146------- 147 148Most device data can be described using the ``VMSTATE`` macros (mostly defined 149in ``include/migration/vmstate.h``). 150 151An example (from hw/input/pckbd.c) 152 153.. code:: c 154 155 static const VMStateDescription vmstate_kbd = { 156 .name = "pckbd", 157 .version_id = 3, 158 .minimum_version_id = 3, 159 .fields = (VMStateField[]) { 160 VMSTATE_UINT8(write_cmd, KBDState), 161 VMSTATE_UINT8(status, KBDState), 162 VMSTATE_UINT8(mode, KBDState), 163 VMSTATE_UINT8(pending, KBDState), 164 VMSTATE_END_OF_LIST() 165 } 166 }; 167 168We are declaring the state with name "pckbd". 169The ``version_id`` is 3, and the fields are 4 uint8_t in a KBDState structure. 170We registered this with: 171 172.. code:: c 173 174 vmstate_register(NULL, 0, &vmstate_kbd, s); 175 176For devices that are ``qdev`` based, we can register the device in the class 177init function: 178 179.. code:: c 180 181 dc->vmsd = &vmstate_kbd_isa; 182 183The VMState macros take care of ensuring that the device data section 184is formatted portably (normally big endian) and make some compile time checks 185against the types of the fields in the structures. 186 187VMState macros can include other VMStateDescriptions to store substructures 188(see ``VMSTATE_STRUCT_``), arrays (``VMSTATE_ARRAY_``) and variable length 189arrays (``VMSTATE_VARRAY_``). Various other macros exist for special 190cases. 191 192Note that the format on the wire is still very raw; i.e. a VMSTATE_UINT32 193ends up with a 4 byte bigendian representation on the wire; in the future 194it might be possible to use a more structured format. 195 196Legacy way 197---------- 198 199This way is going to disappear as soon as all current users are ported to VMSTATE; 200although converting existing code can be tricky, and thus 'soon' is relative. 201 202Each device has to register two functions, one to save the state and 203another to load the state back. 204 205.. code:: c 206 207 int register_savevm_live(const char *idstr, 208 int instance_id, 209 int version_id, 210 SaveVMHandlers *ops, 211 void *opaque); 212 213Two functions in the ``ops`` structure are the ``save_state`` 214and ``load_state`` functions. Notice that ``load_state`` receives a version_id 215parameter to know what state format is receiving. ``save_state`` doesn't 216have a version_id parameter because it always uses the latest version. 217 218Note that because the VMState macros still save the data in a raw 219format, in many cases it's possible to replace legacy code 220with a carefully constructed VMState description that matches the 221byte layout of the existing code. 222 223Changing migration data structures 224---------------------------------- 225 226When we migrate a device, we save/load the state as a series 227of fields. Sometimes, due to bugs or new functionality, we need to 228change the state to store more/different information. Changing the migration 229state saved for a device can break migration compatibility unless 230care is taken to use the appropriate techniques. In general QEMU tries 231to maintain forward migration compatibility (i.e. migrating from 232QEMU n->n+1) and there are users who benefit from backward compatibility 233as well. 234 235Subsections 236----------- 237 238The most common structure change is adding new data, e.g. when adding 239a newer form of device, or adding that state that you previously 240forgot to migrate. This is best solved using a subsection. 241 242A subsection is "like" a device vmstate, but with a particularity, it 243has a Boolean function that tells if that values are needed to be sent 244or not. If this functions returns false, the subsection is not sent. 245Subsections have a unique name, that is looked for on the receiving 246side. 247 248On the receiving side, if we found a subsection for a device that we 249don't understand, we just fail the migration. If we understand all 250the subsections, then we load the state with success. There's no check 251that a subsection is loaded, so a newer QEMU that knows about a subsection 252can (with care) load a stream from an older QEMU that didn't send 253the subsection. 254 255If the new data is only needed in a rare case, then the subsection 256can be made conditional on that case and the migration will still 257succeed to older QEMUs in most cases. This is OK for data that's 258critical, but in some use cases it's preferred that the migration 259should succeed even with the data missing. To support this the 260subsection can be connected to a device property and from there 261to a versioned machine type. 262 263The 'pre_load' and 'post_load' functions on subsections are only 264called if the subsection is loaded. 265 266One important note is that the outer post_load() function is called "after" 267loading all subsections, because a newer subsection could change the same 268value that it uses. A flag, and the combination of outer pre_load and 269post_load can be used to detect whether a subsection was loaded, and to 270fall back on default behaviour when the subsection isn't present. 271 272Example: 273 274.. code:: c 275 276 static bool ide_drive_pio_state_needed(void *opaque) 277 { 278 IDEState *s = opaque; 279 280 return ((s->status & DRQ_STAT) != 0) 281 || (s->bus->error_status & BM_STATUS_PIO_RETRY); 282 } 283 284 const VMStateDescription vmstate_ide_drive_pio_state = { 285 .name = "ide_drive/pio_state", 286 .version_id = 1, 287 .minimum_version_id = 1, 288 .pre_save = ide_drive_pio_pre_save, 289 .post_load = ide_drive_pio_post_load, 290 .needed = ide_drive_pio_state_needed, 291 .fields = (VMStateField[]) { 292 VMSTATE_INT32(req_nb_sectors, IDEState), 293 VMSTATE_VARRAY_INT32(io_buffer, IDEState, io_buffer_total_len, 1, 294 vmstate_info_uint8, uint8_t), 295 VMSTATE_INT32(cur_io_buffer_offset, IDEState), 296 VMSTATE_INT32(cur_io_buffer_len, IDEState), 297 VMSTATE_UINT8(end_transfer_fn_idx, IDEState), 298 VMSTATE_INT32(elementary_transfer_size, IDEState), 299 VMSTATE_INT32(packet_transfer_size, IDEState), 300 VMSTATE_END_OF_LIST() 301 } 302 }; 303 304 const VMStateDescription vmstate_ide_drive = { 305 .name = "ide_drive", 306 .version_id = 3, 307 .minimum_version_id = 0, 308 .post_load = ide_drive_post_load, 309 .fields = (VMStateField[]) { 310 .... several fields .... 311 VMSTATE_END_OF_LIST() 312 }, 313 .subsections = (const VMStateDescription*[]) { 314 &vmstate_ide_drive_pio_state, 315 NULL 316 } 317 }; 318 319Here we have a subsection for the pio state. We only need to 320save/send this state when we are in the middle of a pio operation 321(that is what ``ide_drive_pio_state_needed()`` checks). If DRQ_STAT is 322not enabled, the values on that fields are garbage and don't need to 323be sent. 324 325Connecting subsections to properties 326------------------------------------ 327 328Using a condition function that checks a 'property' to determine whether 329to send a subsection allows backward migration compatibility when 330new subsections are added, especially when combined with versioned 331machine types. 332 333For example: 334 335 a) Add a new property using ``DEFINE_PROP_BOOL`` - e.g. support-foo and 336 default it to true. 337 b) Add an entry to the ``hw_compat_`` for the previous version that sets 338 the property to false. 339 c) Add a static bool support_foo function that tests the property. 340 d) Add a subsection with a .needed set to the support_foo function 341 e) (potentially) Add an outer pre_load that sets up a default value 342 for 'foo' to be used if the subsection isn't loaded. 343 344Now that subsection will not be generated when using an older 345machine type and the migration stream will be accepted by older 346QEMU versions. 347 348Not sending existing elements 349----------------------------- 350 351Sometimes members of the VMState are no longer needed: 352 353 - removing them will break migration compatibility 354 355 - making them version dependent and bumping the version will break backward migration 356 compatibility. 357 358Adding a dummy field into the migration stream is normally the best way to preserve 359compatibility. 360 361If the field really does need to be removed then: 362 363 a) Add a new property/compatibility/function in the same way for subsections above. 364 b) replace the VMSTATE macro with the _TEST version of the macro, e.g.: 365 366 ``VMSTATE_UINT32(foo, barstruct)`` 367 368 becomes 369 370 ``VMSTATE_UINT32_TEST(foo, barstruct, pre_version_baz)`` 371 372 Sometime in the future when we no longer care about the ancient versions these can be killed off. 373 Note that for backward compatibility it's important to fill in the structure with 374 data that the destination will understand. 375 376Any difference in the predicates on the source and destination will end up 377with different fields being enabled and data being loaded into the wrong 378fields; for this reason conditional fields like this are very fragile. 379 380Versions 381-------- 382 383Version numbers are intended for major incompatible changes to the 384migration of a device, and using them breaks backward-migration 385compatibility; in general most changes can be made by adding Subsections 386(see above) or _TEST macros (see above) which won't break compatibility. 387 388Each version is associated with a series of fields saved. The ``save_state`` always saves 389the state as the newer version. But ``load_state`` sometimes is able to 390load state from an older version. 391 392You can see that there are two version fields: 393 394- ``version_id``: the maximum version_id supported by VMState for that device. 395- ``minimum_version_id``: the minimum version_id that VMState is able to understand 396 for that device. 397 398VMState is able to read versions from minimum_version_id to version_id. 399 400There are *_V* forms of many ``VMSTATE_`` macros to load fields for version dependent fields, 401e.g. 402 403.. code:: c 404 405 VMSTATE_UINT16_V(ip_id, Slirp, 2), 406 407only loads that field for versions 2 and newer. 408 409Saving state will always create a section with the 'version_id' value 410and thus can't be loaded by any older QEMU. 411 412Massaging functions 413------------------- 414 415Sometimes, it is not enough to be able to save the state directly 416from one structure, we need to fill the correct values there. One 417example is when we are using kvm. Before saving the cpu state, we 418need to ask kvm to copy to QEMU the state that it is using. And the 419opposite when we are loading the state, we need a way to tell kvm to 420load the state for the cpu that we have just loaded from the QEMUFile. 421 422The functions to do that are inside a vmstate definition, and are called: 423 424- ``int (*pre_load)(void *opaque);`` 425 426 This function is called before we load the state of one device. 427 428- ``int (*post_load)(void *opaque, int version_id);`` 429 430 This function is called after we load the state of one device. 431 432- ``int (*pre_save)(void *opaque);`` 433 434 This function is called before we save the state of one device. 435 436- ``int (*post_save)(void *opaque);`` 437 438 This function is called after we save the state of one device 439 (even upon failure, unless the call to pre_save returned an error). 440 441Example: You can look at hpet.c, that uses the first three functions 442to massage the state that is transferred. 443 444The ``VMSTATE_WITH_TMP`` macro may be useful when the migration 445data doesn't match the stored device data well; it allows an 446intermediate temporary structure to be populated with migration 447data and then transferred to the main structure. 448 449If you use memory API functions that update memory layout outside 450initialization (i.e., in response to a guest action), this is a strong 451indication that you need to call these functions in a ``post_load`` callback. 452Examples of such memory API functions are: 453 454 - memory_region_add_subregion() 455 - memory_region_del_subregion() 456 - memory_region_set_readonly() 457 - memory_region_set_nonvolatile() 458 - memory_region_set_enabled() 459 - memory_region_set_address() 460 - memory_region_set_alias_offset() 461 462Iterative device migration 463-------------------------- 464 465Some devices, such as RAM, Block storage or certain platform devices, 466have large amounts of data that would mean that the CPUs would be 467paused for too long if they were sent in one section. For these 468devices an *iterative* approach is taken. 469 470The iterative devices generally don't use VMState macros 471(although it may be possible in some cases) and instead use 472qemu_put_*/qemu_get_* macros to read/write data to the stream. Specialist 473versions exist for high bandwidth IO. 474 475 476An iterative device must provide: 477 478 - A ``save_setup`` function that initialises the data structures and 479 transmits a first section containing information on the device. In the 480 case of RAM this transmits a list of RAMBlocks and sizes. 481 482 - A ``load_setup`` function that initialises the data structures on the 483 destination. 484 485 - A ``state_pending_exact`` function that indicates how much more 486 data we must save. The core migration code will use this to 487 determine when to pause the CPUs and complete the migration. 488 489 - A ``state_pending_estimate`` function that indicates how much more 490 data we must save. When the estimated amount is smaller than the 491 threshold, we call ``state_pending_exact``. 492 493 - A ``save_live_iterate`` function should send a chunk of data until 494 the point that stream bandwidth limits tell it to stop. Each call 495 generates one section. 496 497 - A ``save_live_complete_precopy`` function that must transmit the 498 last section for the device containing any remaining data. 499 500 - A ``load_state`` function used to load sections generated by 501 any of the save functions that generate sections. 502 503 - ``cleanup`` functions for both save and load that are called 504 at the end of migration. 505 506Note that the contents of the sections for iterative migration tend 507to be open-coded by the devices; care should be taken in parsing 508the results and structuring the stream to make them easy to validate. 509 510Device ordering 511--------------- 512 513There are cases in which the ordering of device loading matters; for 514example in some systems where a device may assert an interrupt during loading, 515if the interrupt controller is loaded later then it might lose the state. 516 517Some ordering is implicitly provided by the order in which the machine 518definition creates devices, however this is somewhat fragile. 519 520The ``MigrationPriority`` enum provides a means of explicitly enforcing 521ordering. Numerically higher priorities are loaded earlier. 522The priority is set by setting the ``priority`` field of the top level 523``VMStateDescription`` for the device. 524 525Stream structure 526================ 527 528The stream tries to be word and endian agnostic, allowing migration between hosts 529of different characteristics running the same VM. 530 531 - Header 532 533 - Magic 534 - Version 535 - VM configuration section 536 537 - Machine type 538 - Target page bits 539 - List of sections 540 Each section contains a device, or one iteration of a device save. 541 542 - section type 543 - section id 544 - ID string (First section of each device) 545 - instance id (First section of each device) 546 - version id (First section of each device) 547 - <device data> 548 - Footer mark 549 - EOF mark 550 - VM Description structure 551 Consisting of a JSON description of the contents for analysis only 552 553The ``device data`` in each section consists of the data produced 554by the code described above. For non-iterative devices they have a single 555section; iterative devices have an initial and last section and a set 556of parts in between. 557Note that there is very little checking by the common code of the integrity 558of the ``device data`` contents, that's up to the devices themselves. 559The ``footer mark`` provides a little bit of protection for the case where 560the receiving side reads more or less data than expected. 561 562The ``ID string`` is normally unique, having been formed from a bus name 563and device address, PCI devices and storage devices hung off PCI controllers 564fit this pattern well. Some devices are fixed single instances (e.g. "pc-ram"). 565Others (especially either older devices or system devices which for 566some reason don't have a bus concept) make use of the ``instance id`` 567for otherwise identically named devices. 568 569Return path 570----------- 571 572Only a unidirectional stream is required for normal migration, however a 573``return path`` can be created when bidirectional communication is desired. 574This is primarily used by postcopy, but is also used to return a success 575flag to the source at the end of migration. 576 577``qemu_file_get_return_path(QEMUFile* fwdpath)`` gives the QEMUFile* for the return 578path. 579 580 Source side 581 582 Forward path - written by migration thread 583 Return path - opened by main thread, read by return-path thread 584 585 Destination side 586 587 Forward path - read by main thread 588 Return path - opened by main thread, written by main thread AND postcopy 589 thread (protected by rp_mutex) 590 591Postcopy 592======== 593 594'Postcopy' migration is a way to deal with migrations that refuse to converge 595(or take too long to converge) its plus side is that there is an upper bound on 596the amount of migration traffic and time it takes, the down side is that during 597the postcopy phase, a failure of *either* side causes the guest to be lost. 598 599In postcopy the destination CPUs are started before all the memory has been 600transferred, and accesses to pages that are yet to be transferred cause 601a fault that's translated by QEMU into a request to the source QEMU. 602 603Postcopy can be combined with precopy (i.e. normal migration) so that if precopy 604doesn't finish in a given time the switch is made to postcopy. 605 606Enabling postcopy 607----------------- 608 609To enable postcopy, issue this command on the monitor (both source and 610destination) prior to the start of migration: 611 612``migrate_set_capability postcopy-ram on`` 613 614The normal commands are then used to start a migration, which is still 615started in precopy mode. Issuing: 616 617``migrate_start_postcopy`` 618 619will now cause the transition from precopy to postcopy. 620It can be issued immediately after migration is started or any 621time later on. Issuing it after the end of a migration is harmless. 622 623Blocktime is a postcopy live migration metric, intended to show how 624long the vCPU was in state of interruptible sleep due to pagefault. 625That metric is calculated both for all vCPUs as overlapped value, and 626separately for each vCPU. These values are calculated on destination 627side. To enable postcopy blocktime calculation, enter following 628command on destination monitor: 629 630``migrate_set_capability postcopy-blocktime on`` 631 632Postcopy blocktime can be retrieved by query-migrate qmp command. 633postcopy-blocktime value of qmp command will show overlapped blocking 634time for all vCPU, postcopy-vcpu-blocktime will show list of blocking 635time per vCPU. 636 637.. note:: 638 During the postcopy phase, the bandwidth limits set using 639 ``migrate_set_parameter`` is ignored (to avoid delaying requested pages that 640 the destination is waiting for). 641 642Postcopy device transfer 643------------------------ 644 645Loading of device data may cause the device emulation to access guest RAM 646that may trigger faults that have to be resolved by the source, as such 647the migration stream has to be able to respond with page data *during* the 648device load, and hence the device data has to be read from the stream completely 649before the device load begins to free the stream up. This is achieved by 650'packaging' the device data into a blob that's read in one go. 651 652Source behaviour 653---------------- 654 655Until postcopy is entered the migration stream is identical to normal 656precopy, except for the addition of a 'postcopy advise' command at 657the beginning, to tell the destination that postcopy might happen. 658When postcopy starts the source sends the page discard data and then 659forms the 'package' containing: 660 661 - Command: 'postcopy listen' 662 - The device state 663 664 A series of sections, identical to the precopy streams device state stream 665 containing everything except postcopiable devices (i.e. RAM) 666 - Command: 'postcopy run' 667 668The 'package' is sent as the data part of a Command: ``CMD_PACKAGED``, and the 669contents are formatted in the same way as the main migration stream. 670 671During postcopy the source scans the list of dirty pages and sends them 672to the destination without being requested (in much the same way as precopy), 673however when a page request is received from the destination, the dirty page 674scanning restarts from the requested location. This causes requested pages 675to be sent quickly, and also causes pages directly after the requested page 676to be sent quickly in the hope that those pages are likely to be used 677by the destination soon. 678 679Destination behaviour 680--------------------- 681 682Initially the destination looks the same as precopy, with a single thread 683reading the migration stream; the 'postcopy advise' and 'discard' commands 684are processed to change the way RAM is managed, but don't affect the stream 685processing. 686 687:: 688 689 ------------------------------------------------------------------------------ 690 1 2 3 4 5 6 7 691 main -----DISCARD-CMD_PACKAGED ( LISTEN DEVICE DEVICE DEVICE RUN ) 692 thread | | 693 | (page request) 694 | \___ 695 v \ 696 listen thread: --- page -- page -- page -- page -- page -- 697 698 a b c 699 ------------------------------------------------------------------------------ 700 701- On receipt of ``CMD_PACKAGED`` (1) 702 703 All the data associated with the package - the ( ... ) section in the diagram - 704 is read into memory, and the main thread recurses into qemu_loadvm_state_main 705 to process the contents of the package (2) which contains commands (3,6) and 706 devices (4...) 707 708- On receipt of 'postcopy listen' - 3 -(i.e. the 1st command in the package) 709 710 a new thread (a) is started that takes over servicing the migration stream, 711 while the main thread carries on loading the package. It loads normal 712 background page data (b) but if during a device load a fault happens (5) 713 the returned page (c) is loaded by the listen thread allowing the main 714 threads device load to carry on. 715 716- The last thing in the ``CMD_PACKAGED`` is a 'RUN' command (6) 717 718 letting the destination CPUs start running. At the end of the 719 ``CMD_PACKAGED`` (7) the main thread returns to normal running behaviour and 720 is no longer used by migration, while the listen thread carries on servicing 721 page data until the end of migration. 722 723Postcopy Recovery 724----------------- 725 726Comparing to precopy, postcopy is special on error handlings. When any 727error happens (in this case, mostly network errors), QEMU cannot easily 728fail a migration because VM data resides in both source and destination 729QEMU instances. On the other hand, when issue happens QEMU on both sides 730will go into a paused state. It'll need a recovery phase to continue a 731paused postcopy migration. 732 733The recovery phase normally contains a few steps: 734 735 - When network issue occurs, both QEMU will go into PAUSED state 736 737 - When the network is recovered (or a new network is provided), the admin 738 can setup the new channel for migration using QMP command 739 'migrate-recover' on destination node, preparing for a resume. 740 741 - On source host, the admin can continue the interrupted postcopy 742 migration using QMP command 'migrate' with resume=true flag set. 743 744 - After the connection is re-established, QEMU will continue the postcopy 745 migration on both sides. 746 747During a paused postcopy migration, the VM can logically still continue 748running, and it will not be impacted from any page access to pages that 749were already migrated to destination VM before the interruption happens. 750However, if any of the missing pages got accessed on destination VM, the VM 751thread will be halted waiting for the page to be migrated, it means it can 752be halted until the recovery is complete. 753 754The impact of accessing missing pages can be relevant to different 755configurations of the guest. For example, when with async page fault 756enabled, logically the guest can proactively schedule out the threads 757accessing missing pages. 758 759Postcopy states 760--------------- 761 762Postcopy moves through a series of states (see postcopy_state) from 763ADVISE->DISCARD->LISTEN->RUNNING->END 764 765 - Advise 766 767 Set at the start of migration if postcopy is enabled, even 768 if it hasn't had the start command; here the destination 769 checks that its OS has the support needed for postcopy, and performs 770 setup to ensure the RAM mappings are suitable for later postcopy. 771 The destination will fail early in migration at this point if the 772 required OS support is not present. 773 (Triggered by reception of POSTCOPY_ADVISE command) 774 775 - Discard 776 777 Entered on receipt of the first 'discard' command; prior to 778 the first Discard being performed, hugepages are switched off 779 (using madvise) to ensure that no new huge pages are created 780 during the postcopy phase, and to cause any huge pages that 781 have discards on them to be broken. 782 783 - Listen 784 785 The first command in the package, POSTCOPY_LISTEN, switches 786 the destination state to Listen, and starts a new thread 787 (the 'listen thread') which takes over the job of receiving 788 pages off the migration stream, while the main thread carries 789 on processing the blob. With this thread able to process page 790 reception, the destination now 'sensitises' the RAM to detect 791 any access to missing pages (on Linux using the 'userfault' 792 system). 793 794 - Running 795 796 POSTCOPY_RUN causes the destination to synchronise all 797 state and start the CPUs and IO devices running. The main 798 thread now finishes processing the migration package and 799 now carries on as it would for normal precopy migration 800 (although it can't do the cleanup it would do as it 801 finishes a normal migration). 802 803 - Paused 804 805 Postcopy can run into a paused state (normally on both sides when 806 happens), where all threads will be temporarily halted mostly due to 807 network errors. When reaching paused state, migration will make sure 808 the qemu binary on both sides maintain the data without corrupting 809 the VM. To continue the migration, the admin needs to fix the 810 migration channel using the QMP command 'migrate-recover' on the 811 destination node, then resume the migration using QMP command 'migrate' 812 again on source node, with resume=true flag set. 813 814 - End 815 816 The listen thread can now quit, and perform the cleanup of migration 817 state, the migration is now complete. 818 819Source side page map 820-------------------- 821 822The 'migration bitmap' in postcopy is basically the same as in the precopy, 823where each of the bit to indicate that page is 'dirty' - i.e. needs 824sending. During the precopy phase this is updated as the CPU dirties 825pages, however during postcopy the CPUs are stopped and nothing should 826dirty anything any more. Instead, dirty bits are cleared when the relevant 827pages are sent during postcopy. 828 829Postcopy with hugepages 830----------------------- 831 832Postcopy now works with hugetlbfs backed memory: 833 834 a) The linux kernel on the destination must support userfault on hugepages. 835 b) The huge-page configuration on the source and destination VMs must be 836 identical; i.e. RAMBlocks on both sides must use the same page size. 837 c) Note that ``-mem-path /dev/hugepages`` will fall back to allocating normal 838 RAM if it doesn't have enough hugepages, triggering (b) to fail. 839 Using ``-mem-prealloc`` enforces the allocation using hugepages. 840 d) Care should be taken with the size of hugepage used; postcopy with 2MB 841 hugepages works well, however 1GB hugepages are likely to be problematic 842 since it takes ~1 second to transfer a 1GB hugepage across a 10Gbps link, 843 and until the full page is transferred the destination thread is blocked. 844 845Postcopy with shared memory 846--------------------------- 847 848Postcopy migration with shared memory needs explicit support from the other 849processes that share memory and from QEMU. There are restrictions on the type of 850memory that userfault can support shared. 851 852The Linux kernel userfault support works on ``/dev/shm`` memory and on ``hugetlbfs`` 853(although the kernel doesn't provide an equivalent to ``madvise(MADV_DONTNEED)`` 854for hugetlbfs which may be a problem in some configurations). 855 856The vhost-user code in QEMU supports clients that have Postcopy support, 857and the ``vhost-user-bridge`` (in ``tests/``) and the DPDK package have changes 858to support postcopy. 859 860The client needs to open a userfaultfd and register the areas 861of memory that it maps with userfault. The client must then pass the 862userfaultfd back to QEMU together with a mapping table that allows 863fault addresses in the clients address space to be converted back to 864RAMBlock/offsets. The client's userfaultfd is added to the postcopy 865fault-thread and page requests are made on behalf of the client by QEMU. 866QEMU performs 'wake' operations on the client's userfaultfd to allow it 867to continue after a page has arrived. 868 869.. note:: 870 There are two future improvements that would be nice: 871 a) Some way to make QEMU ignorant of the addresses in the clients 872 address space 873 b) Avoiding the need for QEMU to perform ufd-wake calls after the 874 pages have arrived 875 876Retro-fitting postcopy to existing clients is possible: 877 a) A mechanism is needed for the registration with userfault as above, 878 and the registration needs to be coordinated with the phases of 879 postcopy. In vhost-user extra messages are added to the existing 880 control channel. 881 b) Any thread that can block due to guest memory accesses must be 882 identified and the implication understood; for example if the 883 guest memory access is made while holding a lock then all other 884 threads waiting for that lock will also be blocked. 885 886Postcopy Preemption Mode 887------------------------ 888 889Postcopy preempt is a new capability introduced in 8.0 QEMU release, it 890allows urgent pages (those got page fault requested from destination QEMU 891explicitly) to be sent in a separate preempt channel, rather than queued in 892the background migration channel. Anyone who cares about latencies of page 893faults during a postcopy migration should enable this feature. By default, 894it's not enabled. 895 896Firmware 897======== 898 899Migration migrates the copies of RAM and ROM, and thus when running 900on the destination it includes the firmware from the source. Even after 901resetting a VM, the old firmware is used. Only once QEMU has been restarted 902is the new firmware in use. 903 904- Changes in firmware size can cause changes in the required RAMBlock size 905 to hold the firmware and thus migration can fail. In practice it's best 906 to pad firmware images to convenient powers of 2 with plenty of space 907 for growth. 908 909- Care should be taken with device emulation code so that newer 910 emulation code can work with older firmware to allow forward migration. 911 912- Care should be taken with newer firmware so that backward migration 913 to older systems with older device emulation code will work. 914 915In some cases it may be best to tie specific firmware versions to specific 916versioned machine types to cut down on the combinations that will need 917support. This is also useful when newer versions of firmware outgrow 918the padding. 919 920