[论文笔记]Live Migration of Virtual Machine Based on Full System Trace and Replay

Introduction

这篇是以华中科大刘海坤博士等人在2009年HPDC大会上的LiveMigrationofVirtualMachineBasedonFullSystemTraceandReplay来进行讨论的。

05年的时候，Xen和VMWare分别推出了里程碑式的关于热迁移方面的论文[1]和[2]，相继提出了pre-copy式的方案，所针对的应用场景皆为同一子网下的LAN。该方案中要迁移的内容大致分3种：1)VM的物理内存。这是最棘手的，因为直接影响到了downtime；2)网络链接和虚拟设备的状态；3)SCSI存储。尽管pre-copy式的热迁移可以大幅减少downtime至毫秒级别，但是仍然有一些问题没有解决：

1)仅限于目前的LAN，因为它无法应对脏页生产速率大于用于迁移的网络带宽的情况；

2)在[1]中提出的”para-virtualizationoptimizations”策略虽然一定程度上优化了WWS过大的问题和减少了不必要的freepages，但也降低了用户的experience，这对一些交互性敏感的服务是致命的(比如低延迟的服务)。

3)没有考虑到CPU缓存数据。尽管不一定会导致targethost出错，但大量的缓存和TLBmissing也许会使VM接手的服务性能下降。

所以，作者基于Revirt[3]提出了CR-TRMotion迁移策略，其目的是为了减少需要传输的总数据，并巧妙地把原本需要传输的数据，利用targethost闲置的资源根据log文件进行replay，使热迁移应用在WAN/MAN下成为可能。

Design

(1)Strategy

CT-RT的基本策略是：首先，sourcehost以copy-on-write的方式生成一个对guestOS透明的checkpoint，并传输给targethost。然后，targethost接收checkpoint完毕，返回消息，sourcehost就以一定时间间隔不断发送logfile，直到达到某终止条件。此期间，sourcehost不停运行service，targethost则不断根据接收得到的logfile进行基于checkpoint的回放。达到终止条件，sourcehost在传输完最后的logfile之后suspend，targethost则在回放完最后的filelog之后接手service。

(2)MigrationProcess

根据论文[3-5]，对于大多数负载而言，log的增长速率是小于1MB/s的，相较于LAN的1Gb/s小很多。而且，log的回放速度必然是大于log的增长速度的，因为在进程在普通执行过程当中会阻塞等待I/O事件，而回放则会skip掉HLT指令造成的空闲等待时间。所以作者们有了一下的设计实现CT-RT的过程，如图1：

Initialization。选择资源充足的targethost，正确的选择会加速迁移并增进QoS。

Reservation。A(sourcehost)发送迁移请求至B(targethost)，并保证B有足够的资源。

Checkpointing。A冻结，并在此瞬间把系统状态以COW的方式复制入一个imagefile。完毕后A照常运行。

IterativeLogTransferring。第一轮迭代，传输checkpointfile至B，期间，A把non-deterministicsystemevents记录在logfile中。接下来的迭代，A传输上一轮迭代中产生的logfile至B，B则从checkpointfile中恢复并不断回放接收到的logfile。因为，log的传输远远比生产速度快，所以总会收敛的。

Waiting-and-Chasing。在经历过若干此迭代之后，上一轮产生的logfile大小小于了设定的某个阈值的时候(作者们默认设定的是1KB)，A询问B是否可以进入Stop-and-Copy阶段，若B回放速度不够快，比如B上未使用的logfile文件大小超过了设定的阈值，B会告知A推迟Stop-and-Copy阶段直到B把logfile回放完毕或达到指定阈值。当然，若B的回放速度足够快，这一阶段是可以跳过不进行的。

Stop-and-Copy。Asuspend，B接收完剩下的logfile(非常小，小于设定的阈值)，并回放之。此时A和B基本一致，若B宕机，A仍然可以恢复运行(post-copy则不行)。

Commitment。B告知A，它已经成功同步了运行状态。A承认了迁移事物，并把所有网络重定向给B，这个时候A才真正停止工作，可以销毁。

ServiceTakingover。B接管A的services。

(3)AlgorithmAnalysis

接下来，作者进行了理论上的算法分析。首先是在fastsynchronization的环境下，该情况下log的回放速度较高，所以可以略过Waiting-and-Chasing阶段。具体过程如图2：

然后在SynchronizationwithWaiting-and-Chasing的情况下进行分析。如图3：

由以上两种情况经过理论推算得到总结论，以下趋势对CT-RT式迁移有利：1)checkpoint文件越小；2)networkbandwidth越大；3)log增长率越小。其中前两个影响因子比第3个要大。

根据推理得到的公式可知，CT-RT方法中造成downtime的因素为finallogfile的传输时间，filelogfile的replay时间以及其他时间(启动，交接服务)。而在fastsynchronization情况下，TMT(总传输时间)主要组成成分为传输checkpoint的时间加上所有logfile的传输时间，而TDT(总传输数据)则为TMT*网络带宽；在SynchronizationwithWaiting-and-Chasing情况下，TMT则不是单纯的TDT/网络带宽，而是checkpoint和logfile1的传输时间加上logfile1-logfilen的回放时间。

Implementation

(1)SystemStructure

如图6：

系统基本是基于Revirt的，只是为了实现策略，修改了loggingmodule并且把日志数据流指向了NIC。VMMkernelmodule和kernelhooks把log记录在hostkernel内存的循环缓冲区中，user-leveldaemon把缓冲区中的数据传输给targethost。

Revirt和现行的pre-copy机制，并不能很好的契合CT-RT，所以进行了如下两项主要修改和优化。

(2)COWCheckpointing

针对Revirt不能进行runtimecheckpointing的缺陷，作者引入了COW机制。过程如下：1)checkpoint请求被受理，VM立即suspend并记录下VCPU的状态，所有VM内存页设置为read-only；2)VM恢复并运行，与此同时，所有内存页面复制入网络传输buffer，并通过网络传输给targethost。在该过程中，所有变脏的页面首先复制到COWbuffer中，然后才被replication提取到网络传输buffer。3)当所有页面被复制，才一齐进行传输。

(3)LocalDeviceMigration

和pre-copy以及post-copy不同，CT-RT若不加限制，可能会对NAS中的同块数据进行先后读写，比如sourcehost先行读写之后，targethost回放再次进行读写。作者们针对此问题采取了对应的方法。对所有在sourceVM上对磁盘的读操作进行拦截并把其相关字节记录在logfile中，在targethost回放期间，所有targetVM对磁盘的读操作也被禁止，并重定向到logfile。在回放期间，所有对磁盘的写操作也被禁止，因为操作并没有改变文件的状态。

Conclusion

CT-RT和pre-copy实现的机制比较类似，区别在于传输的内容不是内存页面而是logfile，所以对带宽的要求并不那么苛刻，总迁移时间和downtime明显缩短，对runningservice影响较小，并且对写密集应用有更好的适用性。需要注意的是对NAS的访问机制要稍加修改，并需要优化Revirt系统的checkpointing，以适应本方法的特殊要求。

但是，在多核环境下，记录和回放内存race的代价是昂贵的。作者们想到的应对策略(未实现)是用VCPU的热插技术，在migration时设置成单VCPU，完成时再设置回来。这种牺牲性能的方法，需要经过实验和pre-copy进行比较，得到在多核环境下的迁移最佳方案。

Reference

[1]LiveMigrationofVirtualMachines

[2]Fasttransparentmigrationforvirtualmachines

[3]ReVirt:Enablingintrusionanalysisthroughvirtual-machineloggingandreplay

[4]ExecRecorder:VM-BasedFull-SystemRelayforAttackAnalysisandSystemRecovery

[5]Retrace:Collectingexecutiontracewithvirtualmachinedeterministicreplay