Curling provides fault tolerant mechanism for KVM. For more info, see 'doc/curling.txt'.
Signed-off-by: Jules Wang <junqing.w...@cs2c.com.cn> --- 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 0000000..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 <full bandwidth> + > migrate -f tcp:<address>:<port> +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
