Version 16 (modified by lvpeng, 13 years ago) (diff) |
---|
Welcome to FGBI Project
Traditional xen-based systems track memory updates by keeping evidence of the dirty pages at each migration epoch. For example, Remus uses the same page size as Xen (for x86, this is 4KB), which is also the granularity for detecting memory changes. FGBI (Fine-Grained Block Idenification) is a mechanism which uses smaller memory blocks (smaller than page sizes) as the granularity for detecting memory changes. FGBI calculates the hash value for each memory block at the beginning of each migration epoch. At the end of each epoch, instead of transferring the whole dirty page, FGBI computes new hash values for each block and compares them with the corresponding old values. Blocks are only modified if their corresponding hash values don’t match. Therefore, FGBI marks such blocks as dirty and replaces the old hash values with the new ones. Afterwards, FGBI only transfers dirty blocks to the backup host.
FGBI is based on The Remus project and our previous efforts Lightweight Live Migration (LLM) mechanism.
Starting Points
- Architecture -- The prototype architecture
- Support Techniques -- Block sharing and hybrid compression support
- Framework -- FGBI Execution flow
- Testbed -- Experimental Environment
- Evaluation -- Benchmark results on our testbed
- LLM -- Our previous effort
- Documentation & Publications
- The Xen Hypervisor -- Xen Open Source Industry Standard For Virtualization
- The Remus project -- Remus Open Source Project
- TracGuide -- Built-in Documentation