Curling provides fault tolerant mechanism for KVM.
For more info, see 'doc/curling.txt'.
Signed-off-by: Jules Wang
---
docs/curling.txt | 51 +++
1 file changed, 51 insertions(+)
create mode 100644 docs/curling.txt
diff --git a/docs/curling.txt b/docs/curling.txt
new file mode 100644
index 000..f506a77
--- /dev/null
+++ b/docs/curling.txt
@@ -0,0 +1,51 @@
+KVM Fault Tolerance Specification
+=
+
+
+Contents:
+=
+* Introduction
+* Usage
+* Design & Implement
+* Performance
+
+Introduction
+
+The goal of Curling(sports) is to provide a fault tolerant(ft for short)
+mechanism for KVM, so that in the event of a hardware failure, the virtual
+machine fails over to the backup in a way that is completely transparent
+to the guest operating system.
+
+
+Usage
+=
+The steps of curling are the same as the steps of live migration except the
+following:
+1. Start ft in the qemu monitor of sender vm by following cmdline:
+ > migrate_set_speed
+ > migrate -f tcp::
+2. Connect to the receiver vm by vnc or spice. The screen of the vm is
displayed
+when ft is ready.
+3. Now, the sender vm is protected by ft, When it encounters a failure,
+the failover kicks in.
+
+
+
+Design & Implement
+==
+* By leveraging live migration feature, we do endless live migrations between
+the sender and receiver, so the two virtual machines are synchronized.
+
+* The receiver does not load vm state once the migration begins, instead, it
+perfetches one whole migration data into a buffer, then loads vm state from
+that buffer afterwards. This "all or nothing" approach prevents the
+broken-in-the-middle problem Kemari has.
+
+* The sender sleeps a little while after each migration, to ease the
+performance penalty entailed by vm_stop and iothread locks. This is a
+tradeoff between performance and accuracy.
+
+
+
+Performance
+===
--
1.8.0.1
