![](https://csdnimg.cn/release/download_crawler_static/15703769/bg3.jpg)
b) VNSnap distributed snapshot.
a) VNSnap distributed snapshot.
pre-snapshot
live-snapshot downtime post-snapshot
1
2
3
VM1 VM2 VM1 VM2
b) HotSnap distributed snapshot.a) VNSnap distributed snapshot.
pre-snapshot
live-snapshot suspended post-snapshot
Arrow1
Arrow2
Arrow3
VM1 VM2 VM1 VM2
SNAPSHOT
Figure 2: Comparison of VNSnap and HotSnap.
tributed snapshot and their problems. Section 3 intro-
duces the HotSnap method, describes the transient snap-
shot, full snapshot and coordinated protocol. Section
4 describes the implementation-specific details on QE-
MU/KVM platform. The experimental results are shown
in Section 5. Finally we present the previous work re-
lated to HotSnap in section 6 and conclude our work in
Section 7.
2 An Analysis of Distributed Snapshot
The distributed snapshot includes independent VM s-
napshot and the coordinated protocol. Stop-and-copy
schema is a simple way to create snapshot of individ-
ual VM, but this schema introduces long downtime of
Guest OS and the upper applications running inside the
VM, thus is impractical in many scenarios that deliver
services to users. The live snapshot technologies lever-
age pre-copy based migration to achieve live snapshot
by iteratively saving the dirty pages to the snapshot file
[12, 18]. In this section, we will analyze the live mi-
gration based distributed snapshot proposed in VNSnap
[18], and explain how it results in TCP backoff problem.
Figure 2(a) demonstrates the procedure of VNSnap
distributed snapshot. Although VNSnap exploits the VI-
OLIN [12] switch to execute the coordinated protocol,
we treat V M
1
as the coordinator for clarity. Upon dis-
tributed snapshot, the coordinator, i.e., V M
1
, will send
SNAPSHOT command to VM
2
, and then create the snap-
shot of V M
1
itself. VNSnap leverages live migration to
iteratively save the dirtied pages into stable storage or re-
served memory region until some requirements are satis-
fied, such as the amount of dirty pages are minor enough,
or the size cannot be further reduced even more iterations
are conducted. Then VNSnap suspends the VM, stores
the final dirty memory pages, saves other devices’ state
and creates the disk snapshot. After these steps, the snap-
shot of VM
1
is over and V M
1
is resumed. Upon receiving
the SNAPSHOT command from VM
1
, V M
2
follows the
same procedure as V M
1
to create its own snapshot. VN-
Snap drops the packets send from the post-snapshot VM
to pre-snapshot VM, to keep the global state consistent.
Take this tiny cluster which consists of two VMs as
an example, the distributed snapshot duration time is
from the start time of V M
1
snapshot to the end time of
V M
2
snapshot (suppose V M
2
finishes snapshot later than
V M
1
), the TCP backoff duration is from the start of V M
1
suspend to the end of V M
2
suspend. The packets re-
sult in TCP backoff fall into three categories: 1) V M
1
is suspended while V M
2
is in live-snapshot, the packets
send from V M
2
to V M
1
will not arrive, as Arrow
1
illus-
trates; 2) V M
1
finishes snapshot and then turns into post-
snapshot state, but V M
2
is before or during snapshot. In
this situation, packets send from V M
1
will be dropped to
keep the consistent state of distributed snapshot. Arrow
2
shows such a case. 3) V M
1
is in post-snapshot, but V M
2
is suspended, V M
2
cannot receive the packets send from
V M
1
, as Arrow
3
shows.
Based on the three types of packets, we can conclude
that two aspects affect the TCP backoff duration in dis-