devel/migration/main.rst

7 QEMU has code to load/save the state of the guest that it is running.
8 These are two complementary operations.  Saving the state just does
9 that, saves the state for each device that the guest is running.
11 state of each device.
14 two times.  I.e. it can only restore the state in one guest that has
25 because some guests run with a lot of state (specially RAM), and it
26 can take a while to move all state from one machine to another.  Live
27 migration allows the guest to continue running while the state is
28 transferred.  Only while the last part of the state is transferred has
73 save/restore state devices.  This infrastructure is shared with the
84 Saving the state of one device
87 For most devices, the state is saved in a single call to the migration
96 - The migration state saved should reflect the device being modelled rather
99   internal state that's not directly visible in a register.
102   the state of the device.  These checks might fail in various ways (e.g.
103   discovering internal state is corrupt or that the guest has done something bad).
108   putting the device into an error state, allowing the rest of the VM to
126 - Take care with internal device state or behaviour that might become
132 - The state of the source should not be changed or destroyed by the
145   device state being loaded into the wrong device.
170 We are declaring the state with name "pckbd".  The ``version_id`` is
208 Each device has to register two functions, one to save the state and
209 another to load the state back.
221 parameter to know what state format is receiving.  ``save_state`` doesn't
232 When we migrate a device, we save/load the state as a series
234 change the state to store more/different information.  Changing the migration
235 state saved for a device can break migration compatibility unless
245 a newer form of device, or adding that state that you previously
256 the subsections, then we load the state with success.  There's no check
325 Here we have a subsection for the pio state.  We only need to
326 save/send this state when we are in the middle of a pio operation
395 the state as the newer version.  But ``load_state`` sometimes is able to
396 load state from an older version.
415 Saving state will always create a section with the 'version_id' value
421 Sometimes, it is not enough to be able to save the state directly
423 example is when we are using kvm.  Before saving the cpu state, we
424 need to ask kvm to copy to QEMU the state that it is using.  And the
425 opposite when we are loading the state, we need a way to tell kvm to
426 load the state for the cpu that we have just loaded from the QEMUFile.
432   This function is called before we load the state of one device.
436   This function is called after we load the state of one device.
440   This function is called before we save the state of one device.
444   This function is called after we save the state of one device
448 to massage the state that is transferred.
471 avoid accessing or changing any other device's state in one of these
529 if the interrupt controller is loaded later then it might lose the state.