http://ieeexplore.ieee.org/do...
虚拟机拷贝是通过从主(物理)机向备机反复热迁移虚拟机(virtual machine live migration)，在事故发生时将虚拟机在备机拉起的技术。在正常运行时，备机的虚拟机处于休眠状态。这个休眠说的更具体点，从机器角度看，不执行指令；从网络角度看，不回ARP。
传统的虚拟机拷贝(virtual machine replication)是这么做的：
主备机都连在同两个局域网段，一根线用来传业务网络包，一根线用来传拷贝网络包；
对于路由器来说，在正常运行期间，永远看到的是主机（因为ARP有回包）；
对虚拟机进行高速拷贝，并热迁移至备机。这个频率一般在一秒钟几次到十几次；
在遇到硬件故障时，拉起备机；
让备机主动发送网络包来更新局域网其他节点，尤其是路由器，和交换机的信息，使其网络可见。
难点来了，即使在很高频次的拷贝，还是会有状态不一致的情况（state inconsistency）。具体是这么产生的：
C:client S:Server 数字:包顺序 SB:Server Backup
C--1->S SB
C<-1--S...SB
C--2->S SB
C<-2--S(挂了，2更新了的状态还没同步给备机)
拉起SB
C--3->SB(SB:2都还没传，你传3给我干嘛)
在论文里面，这个2的回包被称作最后一口气包(lasp gasp packet)。这个状态不一致指的是C和SB的之间的。C认为我要传3，SB认为你应该是2。
那传统虚拟机拷贝是怎么来应对这个最后一口气包的呢，他在主机回包那里加了一层缓存墙，
C--1->S SB
C |1<-S...SB(同步成功了后)
C<-1 S SB
C--2->S
C |2<-S(挂了，2更新了的状态还没同步给备机)
拉起SB
C--2->SB(SB:没毛病)
其实他就是把拷贝和回包做成了同步阻塞操作，S挂掉以后，还没来得及拷贝的虚拟机状态随着最后一口气包一起干掉。有经验的同学很快能看出来，这个对性能会有极恶劣的影响的。并且，为了保证回包缓存不爆炸，传统虚拟机拷贝技术一定要保证非常快的拷贝频率，对系统的压力更是雪上加霜。
逆虚拟机拷贝(reverse virtual machine replication)就是主要解决以上两个问题的。具体机制在下文讲述。
