Lines Matching full:to
7 'Postcopy' migration is a way to deal with migrations that refuse to converge
8 (or take too long to converge) its plus side is that there is an upper bound on
10 the postcopy phase, a failure of *either* side causes the guest to be lost.
13 transferred, and accesses to pages that are yet to be transferred cause
14 a fault that's translated by QEMU into a request to the source QEMU.
17 doesn't finish in a given time the switch is made to postcopy.
22 To enable postcopy, issue this command on the monitor (both source and
23 destination) prior to the start of migration:
27 The normal commands are then used to start a migration, which is still
32 will now cause the transition from precopy to postcopy.
36 Blocktime is a postcopy live migration metric, intended to show how
37 long the vCPU was in state of interruptible sleep due to pagefault.
40 side. To enable postcopy blocktime calculation, enter following
52 ``migrate_set_parameter`` is ignored (to avoid delaying requested pages that
69 setup to ensure the RAM mappings are suitable for later postcopy.
76 Entered on receipt of the first 'discard' command; prior to
78 (using madvise) to ensure that no new huge pages are created
79 during the postcopy phase, and to cause any huge pages that
80 have discards on them to be broken.
85 the destination state to Listen, and starts a new thread
88 on processing the blob. With this thread able to process page
89 reception, the destination now 'sensitises' the RAM to detect
90 any access to missing pages (on Linux using the 'userfault'
95 POSTCOPY_RUN causes the destination to synchronise all
110 Loading of device data may cause the device emulation to access guest RAM
111 that may trigger faults that have to be resolved by the source, as such
112 the migration stream has to be able to respond with page data *during* the
113 device load, and hence the device data has to be read from the stream completely
114 before the device load begins to free the stream up. This is achieved by
120 Until postcopy is entered the migration stream is identical to normal
122 the beginning, to tell the destination that postcopy might happen.
129 A series of sections, identical to the precopy streams device state stream
137 to the destination without being requested (in much the same way as precopy),
140 to be sent quickly, and also causes pages directly after the requested page
141 to be sent quickly in the hope that those pages are likely to be used
149 are processed to change the way RAM is managed, but don't affect the stream
170 to process the contents of the package (2) which contains commands (3,6) and
179 threads device load to carry on.
184 ``CMD_PACKAGED`` (7) the main thread returns to normal running behaviour and
192 where each of the bit to indicate that page is 'dirty' - i.e. needs
204 Comparing to precopy, postcopy is special on error handlings. When any
208 will go into a paused state. It'll need a recovery phase to continue a
222 Source QEMU will go into **POSTCOPY_RECOVER_SETUP** state trying to
227 procedure will be needed to properly synchronize the VM states between
228 the two QEMUs to continue the postcopy migration. For example, there
234 postcopy migration on both sides and go back to **POSTCOPY_ACTIVE**
238 running, and it will not be impacted from any page access to pages that
239 were already migrated to destination VM before the interruption happens.
241 thread will be halted waiting for the page to be migrated, it means it can
244 The impact of accessing missing pages can be relevant to different
257 c) Note that ``-mem-path /dev/hugepages`` will fall back to allocating normal
258 RAM if it doesn't have enough hugepages, triggering (b) to fail.
261 hugepages works well, however 1GB hugepages are likely to be problematic
262 since it takes ~1 second to transfer a 1GB hugepage across a 10Gbps link,
273 (although the kernel doesn't provide an equivalent to ``madvise(MADV_DONTNEED)``
278 to support postcopy.
280 The client needs to open a userfaultfd and register the areas
282 userfaultfd back to QEMU together with a mapping table that allows
283 fault addresses in the clients address space to be converted back to
284 RAMBlock/offsets. The client's userfaultfd is added to the postcopy
286 QEMU performs 'wake' operations on the client's userfaultfd to allow it
287 to continue after a page has arrived.
291 a) Some way to make QEMU ignorant of the addresses in the clients
293 b) Avoiding the need for QEMU to perform ufd-wake calls after the
296 Retro-fitting postcopy to existing clients is possible:
298 and the registration needs to be coordinated with the phases of
299 postcopy. In vhost-user extra messages are added to the existing
301 b) Any thread that can block due to guest memory accesses must be
311 explicitly) to be sent in a separate preempt channel, rather than queued in