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:
39 separately for each vCPU. These values are calculated on destination
41 command on destination monitor:
53   the destination is waiting for).
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
85     the destination state to Listen, and starts a new thread
89     reception, the destination now 'sensitises' the RAM to detect
95     POSTCOPY_RUN causes the destination to synchronise all
122 the beginning, to tell the destination that postcopy might happen.
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.
147 Initially the destination looks the same as precopy, with a single thread
183    letting the destination CPUs start running.  At the end of the
206 fail a migration because VM data resides in both source and destination
218     'migrate-recover' on destination node, preparing for a resume.
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
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
263      and until the full page is transferred the destination thread is blocked.
310 allows urgent pages (those got page fault requested from destination QEMU