qemu/docs/migration.txt
<<
>>
Prefs
   1= Migration =
   2
   3QEMU has code to load/save the state of the guest that it is running.
   4These are two complementary operations.  Saving the state just does
   5that, saves the state for each device that the guest is running.
   6Restoring a guest is just the opposite operation: we need to load the
   7state of each device.
   8
   9For this to work, QEMU has to be launched with the same arguments the
  10two times.  I.e. it can only restore the state in one guest that has
  11the same devices that the one it was saved (this last requirement can
  12be relaxed a bit, but for now we can consider that configuration has
  13to be exactly the same).
  14
  15Once that we are able to save/restore a guest, a new functionality is
  16requested: migration.  This means that QEMU is able to start in one
  17machine and being "migrated" to another machine.  I.e. being moved to
  18another machine.
  19
  20Next was the "live migration" functionality.  This is important
  21because some guests run with a lot of state (specially RAM), and it
  22can take a while to move all state from one machine to another.  Live
  23migration allows the guest to continue running while the state is
  24transferred.  Only while the last part of the state is transferred has
  25the guest to be stopped.  Typically the time that the guest is
  26unresponsive during live migration is the low hundred of milliseconds
  27(notice that this depends on a lot of things).
  28
  29=== Types of migration ===
  30
  31Now that we have talked about live migration, there are several ways
  32to do migration:
  33
  34- tcp migration: do the migration using tcp sockets
  35- unix migration: do the migration using unix sockets
  36- exec migration: do the migration using the stdin/stdout through a process.
  37- fd migration: do the migration using an file descriptor that is
  38  passed to QEMU.  QEMU doesn't care how this file descriptor is opened.
  39
  40All these four migration protocols use the same infrastructure to
  41save/restore state devices.  This infrastructure is shared with the
  42savevm/loadvm functionality.
  43
  44=== State Live Migration ===
  45
  46This is used for RAM and block devices.  It is not yet ported to vmstate.
  47<Fill more information here>
  48
  49=== What is the common infrastructure ===
  50
  51QEMU uses a QEMUFile abstraction to be able to do migration.  Any type
  52of migration that wants to use QEMU infrastructure has to create a
  53QEMUFile with:
  54
  55QEMUFile *qemu_fopen_ops(void *opaque,
  56                         QEMUFilePutBufferFunc *put_buffer,
  57                         QEMUFileGetBufferFunc *get_buffer,
  58                         QEMUFileCloseFunc *close);
  59
  60The functions have the following functionality:
  61
  62This function writes a chunk of data to a file at the given position.
  63The pos argument can be ignored if the file is only used for
  64streaming.  The handler should try to write all of the data it can.
  65
  66typedef int (QEMUFilePutBufferFunc)(void *opaque, const uint8_t *buf,
  67                                    int64_t pos, int size);
  68
  69Read a chunk of data from a file at the given position.  The pos argument
  70can be ignored if the file is only be used for streaming.  The number of
  71bytes actually read should be returned.
  72
  73typedef int (QEMUFileGetBufferFunc)(void *opaque, uint8_t *buf,
  74                                    int64_t pos, int size);
  75
  76Close a file and return an error code.
  77
  78typedef int (QEMUFileCloseFunc)(void *opaque);
  79
  80You can use any internal state that you need using the opaque void *
  81pointer that is passed to all functions.
  82
  83The important functions for us are put_buffer()/get_buffer() that
  84allow to write/read a buffer into the QEMUFile.
  85
  86=== How to save the state of one device ===
  87
  88The state of a device is saved using intermediate buffers.  There are
  89some helper functions to assist this saving.
  90
  91There is a new concept that we have to explain here: device state
  92version.  When we migrate a device, we save/load the state as a series
  93of fields.  Some times, due to bugs or new functionality, we need to
  94change the state to store more/different information.  We use the
  95version to identify each time that we do a change.  Each version is
  96associated with a series of fields saved.  The save_state always saves
  97the state as the newer version.  But load_state sometimes is able to
  98load state from an older version.
  99
 100=== Legacy way ===
 101
 102This way is going to disappear as soon as all current users are ported to VMSTATE.
 103
 104Each device has to register two functions, one to save the state and
 105another to load the state back.
 106
 107int register_savevm(DeviceState *dev,
 108                    const char *idstr,
 109                    int instance_id,
 110                    int version_id,
 111                    SaveStateHandler *save_state,
 112                    LoadStateHandler *load_state,
 113                    void *opaque);
 114
 115typedef void SaveStateHandler(QEMUFile *f, void *opaque);
 116typedef int LoadStateHandler(QEMUFile *f, void *opaque, int version_id);
 117
 118The important functions for the device state format are the save_state
 119and load_state.  Notice that load_state receives a version_id
 120parameter to know what state format is receiving.  save_state doesn't
 121have a version_id parameter because it always uses the latest version.
 122
 123=== VMState ===
 124
 125The legacy way of saving/loading state of the device had the problem
 126that we have to maintain two functions in sync.  If we did one change
 127in one of them and not in the other, we would get a failed migration.
 128
 129VMState changed the way that state is saved/loaded.  Instead of using
 130a function to save the state and another to load it, it was changed to
 131a declarative way of what the state consisted of.  Now VMState is able
 132to interpret that definition to be able to load/save the state.  As
 133the state is declared only once, it can't go out of sync in the
 134save/load functions.
 135
 136An example (from hw/input/pckbd.c)
 137
 138static const VMStateDescription vmstate_kbd = {
 139    .name = "pckbd",
 140    .version_id = 3,
 141    .minimum_version_id = 3,
 142    .fields = (VMStateField[]) {
 143        VMSTATE_UINT8(write_cmd, KBDState),
 144        VMSTATE_UINT8(status, KBDState),
 145        VMSTATE_UINT8(mode, KBDState),
 146        VMSTATE_UINT8(pending, KBDState),
 147        VMSTATE_END_OF_LIST()
 148    }
 149};
 150
 151We are declaring the state with name "pckbd".
 152The version_id is 3, and the fields are 4 uint8_t in a KBDState structure.
 153We registered this with:
 154
 155    vmstate_register(NULL, 0, &vmstate_kbd, s);
 156
 157Note: talk about how vmstate <-> qdev interact, and what the instance ids mean.
 158
 159You can search for VMSTATE_* macros for lots of types used in QEMU in
 160include/hw/hw.h.
 161
 162=== More about versions ===
 163
 164You can see that there are several version fields:
 165
 166- version_id: the maximum version_id supported by VMState for that device.
 167- minimum_version_id: the minimum version_id that VMState is able to understand
 168  for that device.
 169- minimum_version_id_old: For devices that were not able to port to vmstate, we can
 170  assign a function that knows how to read this old state. This field is
 171  ignored if there is no load_state_old handler.
 172
 173So, VMState is able to read versions from minimum_version_id to
 174version_id.  And the function load_state_old() (if present) is able to
 175load state from minimum_version_id_old to minimum_version_id.  This
 176function is deprecated and will be removed when no more users are left.
 177
 178===  Massaging functions ===
 179
 180Sometimes, it is not enough to be able to save the state directly
 181from one structure, we need to fill the correct values there.  One
 182example is when we are using kvm.  Before saving the cpu state, we
 183need to ask kvm to copy to QEMU the state that it is using.  And the
 184opposite when we are loading the state, we need a way to tell kvm to
 185load the state for the cpu that we have just loaded from the QEMUFile.
 186
 187The functions to do that are inside a vmstate definition, and are called:
 188
 189- int (*pre_load)(void *opaque);
 190
 191  This function is called before we load the state of one device.
 192
 193- int (*post_load)(void *opaque, int version_id);
 194
 195  This function is called after we load the state of one device.
 196
 197- void (*pre_save)(void *opaque);
 198
 199  This function is called before we save the state of one device.
 200
 201Example: You can look at hpet.c, that uses the three function to
 202         massage the state that is transferred.
 203
 204If you use memory API functions that update memory layout outside
 205initialization (i.e., in response to a guest action), this is a strong
 206indication that you need to call these functions in a post_load callback.
 207Examples of such memory API functions are:
 208
 209  - memory_region_add_subregion()
 210  - memory_region_del_subregion()
 211  - memory_region_set_readonly()
 212  - memory_region_set_enabled()
 213  - memory_region_set_address()
 214  - memory_region_set_alias_offset()
 215
 216=== Subsections ===
 217
 218The use of version_id allows to be able to migrate from older versions
 219to newer versions of a device.  But not the other way around.  This
 220makes very complicated to fix bugs in stable branches.  If we need to
 221add anything to the state to fix a bug, we have to disable migration
 222to older versions that don't have that bug-fix (i.e. a new field).
 223
 224But sometimes, that bug-fix is only needed sometimes, not always.  For
 225instance, if the device is in the middle of a DMA operation, it is
 226using a specific functionality, ....
 227
 228It is impossible to create a way to make migration from any version to
 229any other version to work.  But we can do better than only allowing
 230migration from older versions to newer ones.  For that fields that are
 231only needed sometimes, we add the idea of subsections.  A subsection
 232is "like" a device vmstate, but with a particularity, it has a Boolean
 233function that tells if that values are needed to be sent or not.  If
 234this functions returns false, the subsection is not sent.
 235
 236On the receiving side, if we found a subsection for a device that we
 237don't understand, we just fail the migration.  If we understand all
 238the subsections, then we load the state with success.
 239
 240One important note is that the post_load() function is called "after"
 241loading all subsections, because a newer subsection could change same
 242value that it uses.
 243
 244Example:
 245
 246static bool ide_drive_pio_state_needed(void *opaque)
 247{
 248    IDEState *s = opaque;
 249
 250    return ((s->status & DRQ_STAT) != 0)
 251        || (s->bus->error_status & BM_STATUS_PIO_RETRY);
 252}
 253
 254const VMStateDescription vmstate_ide_drive_pio_state = {
 255    .name = "ide_drive/pio_state",
 256    .version_id = 1,
 257    .minimum_version_id = 1,
 258    .pre_save = ide_drive_pio_pre_save,
 259    .post_load = ide_drive_pio_post_load,
 260    .needed = ide_drive_pio_state_needed,
 261    .fields = (VMStateField[]) {
 262        VMSTATE_INT32(req_nb_sectors, IDEState),
 263        VMSTATE_VARRAY_INT32(io_buffer, IDEState, io_buffer_total_len, 1,
 264                             vmstate_info_uint8, uint8_t),
 265        VMSTATE_INT32(cur_io_buffer_offset, IDEState),
 266        VMSTATE_INT32(cur_io_buffer_len, IDEState),
 267        VMSTATE_UINT8(end_transfer_fn_idx, IDEState),
 268        VMSTATE_INT32(elementary_transfer_size, IDEState),
 269        VMSTATE_INT32(packet_transfer_size, IDEState),
 270        VMSTATE_END_OF_LIST()
 271    }
 272};
 273
 274const VMStateDescription vmstate_ide_drive = {
 275    .name = "ide_drive",
 276    .version_id = 3,
 277    .minimum_version_id = 0,
 278    .post_load = ide_drive_post_load,
 279    .fields = (VMStateField[]) {
 280        .... several fields ....
 281        VMSTATE_END_OF_LIST()
 282    },
 283    .subsections = (const VMStateDescription*[]) {
 284        &vmstate_ide_drive_pio_state,
 285        NULL
 286    }
 287};
 288
 289Here we have a subsection for the pio state.  We only need to
 290save/send this state when we are in the middle of a pio operation
 291(that is what ide_drive_pio_state_needed() checks).  If DRQ_STAT is
 292not enabled, the values on that fields are garbage and don't need to
 293be sent.
 294
 295= Return path =
 296
 297In most migration scenarios there is only a single data path that runs
 298from the source VM to the destination, typically along a single fd (although
 299possibly with another fd or similar for some fast way of throwing pages across).
 300
 301However, some uses need two way communication; in particular the Postcopy
 302destination needs to be able to request pages on demand from the source.
 303
 304For these scenarios there is a 'return path' from the destination to the source;
 305qemu_file_get_return_path(QEMUFile* fwdpath) gives the QEMUFile* for the return
 306path.
 307
 308  Source side
 309     Forward path - written by migration thread
 310     Return path  - opened by main thread, read by return-path thread
 311
 312  Destination side
 313     Forward path - read by main thread
 314     Return path  - opened by main thread, written by main thread AND postcopy
 315                    thread (protected by rp_mutex)
 316
 317= Postcopy =
 318'Postcopy' migration is a way to deal with migrations that refuse to converge
 319(or take too long to converge) its plus side is that there is an upper bound on
 320the amount of migration traffic and time it takes, the down side is that during
 321the postcopy phase, a failure of *either* side or the network connection causes
 322the guest to be lost.
 323
 324In postcopy the destination CPUs are started before all the memory has been
 325transferred, and accesses to pages that are yet to be transferred cause
 326a fault that's translated by QEMU into a request to the source QEMU.
 327
 328Postcopy can be combined with precopy (i.e. normal migration) so that if precopy
 329doesn't finish in a given time the switch is made to postcopy.
 330
 331=== Enabling postcopy ===
 332
 333To enable postcopy, issue this command on the monitor prior to the
 334start of migration:
 335
 336migrate_set_capability postcopy-ram on
 337
 338The normal commands are then used to start a migration, which is still
 339started in precopy mode.  Issuing:
 340
 341migrate_start_postcopy
 342
 343will now cause the transition from precopy to postcopy.
 344It can be issued immediately after migration is started or any
 345time later on.  Issuing it after the end of a migration is harmless.
 346
 347Note: During the postcopy phase, the bandwidth limits set using
 348migrate_set_speed is ignored (to avoid delaying requested pages that
 349the destination is waiting for).
 350
 351=== Postcopy device transfer ===
 352
 353Loading of device data may cause the device emulation to access guest RAM
 354that may trigger faults that have to be resolved by the source, as such
 355the migration stream has to be able to respond with page data *during* the
 356device load, and hence the device data has to be read from the stream completely
 357before the device load begins to free the stream up.  This is achieved by
 358'packaging' the device data into a blob that's read in one go.
 359
 360Source behaviour
 361
 362Until postcopy is entered the migration stream is identical to normal
 363precopy, except for the addition of a 'postcopy advise' command at
 364the beginning, to tell the destination that postcopy might happen.
 365When postcopy starts the source sends the page discard data and then
 366forms the 'package' containing:
 367
 368   Command: 'postcopy listen'
 369   The device state
 370      A series of sections, identical to the precopy streams device state stream
 371      containing everything except postcopiable devices (i.e. RAM)
 372   Command: 'postcopy run'
 373
 374The 'package' is sent as the data part of a Command: 'CMD_PACKAGED', and the
 375contents are formatted in the same way as the main migration stream.
 376
 377During postcopy the source scans the list of dirty pages and sends them
 378to the destination without being requested (in much the same way as precopy),
 379however when a page request is received from the destination, the dirty page
 380scanning restarts from the requested location.  This causes requested pages
 381to be sent quickly, and also causes pages directly after the requested page
 382to be sent quickly in the hope that those pages are likely to be used
 383by the destination soon.
 384
 385Destination behaviour
 386
 387Initially the destination looks the same as precopy, with a single thread
 388reading the migration stream; the 'postcopy advise' and 'discard' commands
 389are processed to change the way RAM is managed, but don't affect the stream
 390processing.
 391
 392------------------------------------------------------------------------------
 393                        1      2   3     4 5                      6   7
 394main -----DISCARD-CMD_PACKAGED ( LISTEN  DEVICE     DEVICE DEVICE RUN )
 395thread                             |       |
 396                                   |     (page request)
 397                                   |        \___
 398                                   v            \
 399listen thread:                     --- page -- page -- page -- page -- page --
 400
 401                                   a   b        c
 402------------------------------------------------------------------------------
 403
 404On receipt of CMD_PACKAGED (1)
 405   All the data associated with the package - the ( ... ) section in the
 406diagram - is read into memory (into a QEMUSizedBuffer), and the main thread
 407recurses into qemu_loadvm_state_main to process the contents of the package (2)
 408which contains commands (3,6) and devices (4...)
 409
 410On receipt of 'postcopy listen' - 3 -(i.e. the 1st command in the package)
 411a new thread (a) is started that takes over servicing the migration stream,
 412while the main thread carries on loading the package.   It loads normal
 413background page data (b) but if during a device load a fault happens (5) the
 414returned page (c) is loaded by the listen thread allowing the main threads
 415device load to carry on.
 416
 417The last thing in the CMD_PACKAGED is a 'RUN' command (6) letting the destination
 418CPUs start running.
 419At the end of the CMD_PACKAGED (7) the main thread returns to normal running behaviour
 420and is no longer used by migration, while the listen thread carries
 421on servicing page data until the end of migration.
 422
 423=== Postcopy states ===
 424
 425Postcopy moves through a series of states (see postcopy_state) from
 426ADVISE->DISCARD->LISTEN->RUNNING->END
 427
 428  Advise:  Set at the start of migration if postcopy is enabled, even
 429           if it hasn't had the start command; here the destination
 430           checks that its OS has the support needed for postcopy, and performs
 431           setup to ensure the RAM mappings are suitable for later postcopy.
 432           The destination will fail early in migration at this point if the
 433           required OS support is not present.
 434           (Triggered by reception of POSTCOPY_ADVISE command)
 435
 436  Discard: Entered on receipt of the first 'discard' command; prior to
 437           the first Discard being performed, hugepages are switched off
 438           (using madvise) to ensure that no new huge pages are created
 439           during the postcopy phase, and to cause any huge pages that
 440           have discards on them to be broken.
 441
 442  Listen:  The first command in the package, POSTCOPY_LISTEN, switches
 443           the destination state to Listen, and starts a new thread
 444           (the 'listen thread') which takes over the job of receiving
 445           pages off the migration stream, while the main thread carries
 446           on processing the blob.  With this thread able to process page
 447           reception, the destination now 'sensitises' the RAM to detect
 448           any access to missing pages (on Linux using the 'userfault'
 449           system).
 450
 451  Running: POSTCOPY_RUN causes the destination to synchronise all
 452           state and start the CPUs and IO devices running.  The main
 453           thread now finishes processing the migration package and
 454           now carries on as it would for normal precopy migration
 455           (although it can't do the cleanup it would do as it
 456           finishes a normal migration).
 457
 458  End:     The listen thread can now quit, and perform the cleanup of migration
 459           state, the migration is now complete.
 460
 461=== Source side page maps ===
 462
 463The source side keeps two bitmaps during postcopy; 'the migration bitmap'
 464and 'unsent map'.  The 'migration bitmap' is basically the same as in
 465the precopy case, and holds a bit to indicate that page is 'dirty' -
 466i.e. needs sending.  During the precopy phase this is updated as the CPU
 467dirties pages, however during postcopy the CPUs are stopped and nothing
 468should dirty anything any more.
 469
 470The 'unsent map' is used for the transition to postcopy. It is a bitmap that
 471has a bit cleared whenever a page is sent to the destination, however during
 472the transition to postcopy mode it is combined with the migration bitmap
 473to form a set of pages that:
 474   a) Have been sent but then redirtied (which must be discarded)
 475   b) Have not yet been sent - which also must be discarded to cause any
 476      transparent huge pages built during precopy to be broken.
 477
 478Note that the contents of the unsentmap are sacrificed during the calculation
 479of the discard set and thus aren't valid once in postcopy.  The dirtymap
 480is still valid and is used to ensure that no page is sent more than once.  Any
 481request for a page that has already been sent is ignored.  Duplicate requests
 482such as this can happen as a page is sent at about the same time the
 483destination accesses it.
 484
 485