Features/PostCopyLiveMigration: Difference between revisions
(→design) |
|||
| Line 12: | Line 12: | ||
As much as possible the design attempts to build reusable components that other features can reuse. | As much as possible the design attempts to build reusable components that other features can reuse. | ||
This postcopy implementation uses the Linux 'userfault' kernel | This postcopy implementation uses the Linux 'userfault' and 'remap_anon_pages' 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). | to Postcopy and is designed to allow use with all of the standard kernel features (like transparent huge pages, KSM etc). | ||
| Line 18: | Line 18: | ||
has been stated (as long as postcopy mode has been enabled first by a capability) | has been stated (as long as postcopy mode has been enabled first by a capability) | ||
[[File:postcopyflow.svg]] | |||
=== Major components === | === Major components === | ||
Revision as of 10:38, 30 September 2014
summary
post-copy based live migration
owner
- Name: Dave Gilbert
- Email: dgilbert@redhat.com
description
A postcopy implementation that allows migration of guests that have large page change rates (relative to the avialable bandwidth) to be migrated in a finite time.
design
As much as possible the design attempts to build reusable components that other features can reuse.
This postcopy implementation uses the Linux 'userfault' and 'remap_anon_pages' 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).
Mixed pre/post copy is built into the design from the start; a command is sent to switch modes after the migration has been stated (as long as postcopy mode has been enabled first by a capability)
Major components
- '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
- '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.
TODO
future enhancement
- optimization - rate limit the background page transmission to reduce the impact on the latency of postcopy page requests.
- Integration with RDMA