http://ieeeexplore.ieee.org/do...虚拟机复制是通过将虚拟机从主（物理）机器反复实时迁移到备机（virtualmachinelivemigration），发生意外时，在备机上拉起虚拟机的技术。在正常运行期间，备用机的虚拟机处于休眠状态。这种休眠更具体。从机器的角度来看，没有指令被执行；从网络的角度来看，没有返回ARP。传统的虚拟机复制（virtualmachinereplication）是这样进行的：主备机连接在同一个局域网的两个网段，一条线用于传输业务网络包，另一条线用于传输和复制网络数据包；对于路由器，也就是说，在正常运行期间，始终看到主机（因为ARP有回复数据包）；虚拟机高速复制并热迁移到备机。这个频率一般是每秒几到十次；当出现硬件故障时，拉起备用机；让备机主动发送网络包来更新局域网内其他节点的信息，尤其是路由器、交换机等，使网络可见。难点来了，即使是非常高频的副本，还是会出现状态不一致的情况。具体是这样生成的：C:clientS:Servernumber:packageorderSB:ServerBackupC--1->SSBC<-1--S...SBC--2->SSBC<-2--S（挂了，2的更新状态还没有同步到备机）拉起SBC--3->SB（SB:2还没有传过来，为什么把3传给我）在论文中，这个2包的响应称为laspgasp包。这种状态不一致指的是C和SB之间。C认为我要传3，SB认为你应该传2。那传统的虚拟机副本怎么处理这个最后一口气的包呢？他在宿主机的回复包上加了一层缓存墙，C--1->SSBC|1<-S...SB(同步成功后)C<-1SSBC--2->SC|2<-S(hanging,2的更新状态还没有同步到备机)pullupSBC--2->SB(SB:nothingwrong)其实他只是把copy和returnpacket做了一个同步阻塞操作。S挂掉后，还没有来得及复制的虚拟机状态会连同最后一口气包一起被杀掉。有经验的同学很快就能看出来，这会对性能造成非常不好的影响。而且，传统的虚拟机拷贝技术为了保证回包缓存不爆，必须保证非常快的拷贝频率，对系统的压力更大。反向虚拟机复制（reversevirtualmachinereplication）主要解决以上两个问题。具体机制如下所述。
