devel/migration/postcopy.rst

12 In postcopy the destination CPUs are started before all the memory has been
23 destination) prior to the start of migration:
25 ``migrate_set_capability postcopy-ram on``
39 separately for each vCPU. These values are calculated on destination
41 command on destination monitor:
43 ``migrate_set_capability postcopy-blocktime on``
45 Postcopy blocktime can be retrieved by query-migrate qmp command.
46 postcopy-blocktime value of qmp command will show overlapped blocking
47 time for all vCPU, postcopy-vcpu-blocktime will show list of blocking
53   the destination is waiting for).
59 -------------
62 ADVISE->DISCARD->LISTEN->RUNNING->END
64  - Advise
67     if it hasn't had the start command; here the destination
70     The destination will fail early in migration at this point if the
74  - Discard
82  - Listen
85     the destination state to Listen, and starts a new thread
89     reception, the destination now 'sensitises' the RAM to detect
93  - Running
95     POSTCOPY_RUN causes the destination to synchronise all
102  - End
108 ---------------
118 ----------------
122 the beginning, to tell the destination that postcopy might happen.
126    - Command: 'postcopy listen'
127    - The device state
131    - Command: 'postcopy run'
137 to the destination without being requested (in much the same way as precopy),
138 however when a page request is received from the destination, the dirty page
142 by the destination soon.
144 Destination behaviour
145 ---------------------
147 Initially the destination looks the same as precopy, with a single thread
154   ------------------------------------------------------------------------------
156   main -----DISCARD-CMD_PACKAGED ( LISTEN  DEVICE     DEVICE DEVICE RUN )
161   listen thread:                     --- page -- page -- page -- page -- page --
164   ------------------------------------------------------------------------------
166 - On receipt of ``CMD_PACKAGED`` (1)
168    All the data associated with the package - the ( ... ) section in the diagram -
173 - On receipt of 'postcopy listen' - 3 -(i.e. the 1st command in the package)
181 - The last thing in the ``CMD_PACKAGED`` is a 'RUN' command (6)
183    letting the destination CPUs start running.  At the end of the
189 -----------------------
192 where each of the bit to indicate that page is 'dirty' - i.e. needs
202 -----------------
206 fail a migration because VM data resides in both source and destination
213   - When network issue occurs, both QEMU will go into **POSTCOPY_PAUSED**
216   - When the network is recovered (or a new network is provided), the admin
218     'migrate-recover' on destination node, preparing for a resume.
220   - On source host, the admin can continue the interrupted postcopy
223     re-establish the channels.
225   - When both sides of QEMU successfully reconnect using a new or fixed up
230     interrupted, then the handshake will guarantee pages lost in-flight
233   - After a proper handshake synchronization, QEMU will continue the
239 were already migrated to destination VM before the interruption happens.
240 However, if any of the missing pages got accessed on destination VM, the VM
250 -----------------------
254   a) The linux kernel on the destination must support userfault on hugepages.
255   b) The huge-page configuration on the source and destination VMs must be
257   c) Note that ``-mem-path /dev/hugepages``  will fall back to allocating normal
259      Using ``-mem-prealloc`` enforces the allocation using hugepages.
263      and until the full page is transferred the destination thread is blocked.
266 ---------------------------
276 The vhost-user code in QEMU supports clients that have Postcopy support,
277 and the ``vhost-user-bridge`` (in ``tests/``) and the DPDK package have changes
285 fault-thread and page requests are made on behalf of the client by QEMU.
293     b) Avoiding the need for QEMU to perform ufd-wake calls after the
296 Retro-fitting postcopy to existing clients is possible:
299      postcopy.  In vhost-user extra messages are added to the existing
307 ------------------------
310 allows urgent pages (those got page fault requested from destination QEMU