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