《The Design of a Practical System for Fault-Tolerant Virtual Machines》
FT Protocol
primary挂了，backup VM接管后很可能初始状态和primary挂的时候不一样
因为non-deterministic events发生了，但是没有同步到，只同步了deterministic
当backup VM满足了Output Requirement，这些信息不会丢失
Output Requirement
当backup收到所有信息后（log entry），primary才向外输出结果output operation
这些log entry 会让它运行到primary执行output operation前最后一个log entry
Primary 可以继续执行其他任务，等收到backup的ACK后再异步output operation
Tcp、OS等基础设施能处理网络传输中的丢包
不能保证所有操作只做了一遍
Primary Failure
backup先运行到最后一个log entry，再像正常server一样运作
此时，backup升为primary，并广播它的MAC地址
Backup Failure
Primary 不再将log entry往logging channel里发
UDP HeartBeat
Log entry流或ACK流的停止发送一段时间表示挂了
Split-Brain
若因为网络延迟导致backup认为primary挂了，然后go live，而primary并没有挂，就会有两个primary
共享存储
当一个server要go live时，先在共享存储上执行一个原子性的test-and-set
成功：go live
失败：已经有一个primary
无法访问：等待直到能访问，服务被挂起
Starting and Restarting
启动一个backup，达到和primary相同的状态
复制VM到远程机器
建立logging channel
原VM成为Primary，复制过去的VM成为backup
此过程暂停primary运行的时间小于1秒
选择backup机器的条件
由于所有机器都用同一个共享存储，所以集群上所有机器都可以是backup
实现了一个clustering service，要复制时直接问service
Logging Channel
hypervisor有大buffer
primary运行时将log放入log buffer，log buffer中的内容会马上刷入logging channel，到达backup后会被读入backup的log buffer，每当backup读入都会给primary发ACK
生产者-消费者模式
primary等待策略
如果primary处理太快，backup太慢，会导致log buffer满，从而导致对外延迟变高
backup的ACK会带一个primary到backup的延迟时间
如果出现大延迟（>1s），primary会占用更少的CPU，以慢下来，初始只减少很少的百分比
动态调整CPU占用来匹配backup的速度
这种CPU占用减小其实发生频率很小
Control Entry
如果primary显示关闭电源，backup也应该停止
资源管理变更也要同步到backup，如增加CPU共享
这些control entry也将发入logging channel
Disk IO Issues
Disk operation可以是异步的，那么操作相同的disk位置可能会non-determinism
解决方案：检测这种race，强制顺序执行
内存冲突
通过DMA操作相同位置的内存引发冲突
解决方案：页保护
Bounce buffer
读：数据先读到bounce buffer，IO完成才会将数据读到guest memory
写：数据先写到bounce buffer，再从bounce buffer写到disk
未解决的问题
3.4最后一段
primary挂了，backup接管，backup不清楚disk IO是否正常完成了
Network IO Issues
Receive buffer可以被hypervisor直接更新
解决方案：禁用异步网络优化
强制guest捕获hypervisor，log the update，然后操作给VM
禁用从transmit queue中拿数据包，取而代之，捕获hypervisor来通信
设计选择
由于共享disk是在外部，写共享disk相当于一次外部交互，有延迟，所以只有primary写
如果backup也要一个不共享的disk，也负责写，就有同步问题
backup也从不从共享disk中读
仅在单处理器机器上实现