Features/PostCopyLiveMigration

summary

post-copy based live migration (merged in 2.5)

owner

Name: Dave Gilbert
Email: dgilbert@redhat.com

Current Status

Last updated: 2015-11-24
Released in: QEMU 2.5

Summary

A postcopy implementation that allows migration of guests that have large page change rates (relative to the available bandwidth) to be migrated in a finite time. VMs of any size running any workload can be migrated.

How to use

Enables postcopy mode before the start of migration:

 migrate_set_capability x-postcopy-ram on

Start the migration as normal:

 migrate tcp:destination:port

Change into postcopy mode; this can be issued any time after the start of migration, for most workloads it's best to wait until one cycle of RAM migration has completed (i.e. the sync count hits 2 in info migrate).

 migrate_start_postcopy

Design

This postcopy implementation uses the Linux 'userfaultfd' kernel mechanisms from Andrea Arcangeli; it's not specific to postcopy and is designed to allow use with all of the standard kernel features (like transparent huge pages, KSM etc). It requires Linux 4.3 or newer.

At the start of postcopy mode, all RAM Blocks are registered with 'userfaultfd' so that any accesses to those pages cause the accessing thread to pause. A separate thread reads messages from the kernel about pages that have been accessed and forwards requests to the source host. The source host queues those requests and sends the pages ahead of any background page sending (which still carries on during postcopy mode). As pages arrive on the destination they are placed into memory using new ioctl's that are associated with userfaultfd that cause the page to be copied into the address space atomically and the paused threads to continue.

The guest page faults are asynchronous, so that multiple page faults can be outstanding at once allowing useful work to continue inspite of the latency of providing the page.

Major components

Where possible the design attempts to build reusable components that other features can reuse.

'command' section type for sending migration commands that don't directly reflect guest state; this is used to send messages that move through different phases of postcopy and is expandable for use by others.
'return path' a method for the destination to send messages back to the source; used for postcopy page requests, and allows the destination to signal failure back to the source; this is currently supported on TCP and fd (where the fd is socket backed).
'sent map' a bitmap on the source populated with the set of all pages that have already been transmitted
'postcopy pagemap inbound (PMI)' a map on the destination holding the state of each page, whether it's been requested from the source and whether it has been received.

Other than the 'command' section, the outgoing migration protocol is unchanged.

TODO

future enhancement

optimization - rate limit the background page transmission to reduce the impact on the latency of postcopy page requests.
Integration with RDMA
Handle huge pages & mappings from files.