Changes between Version 31 and Version 32 of VDEchp

Timestamp:

10/06/11 23:25:46 (13 years ago)

Author:

lvpeng

Comment:

--

VDEchp

@@ -39 +39 @@
 We develop a variant of the simplified version of Mattern’s algorithm used in [http://friends.cs.purdue.edu/dokuwiki/doku.php?id=vnsnap VNsnap], as the basis of our lightweight checkpoint mechanism. As illustrated before, type (3) messages are unwanted, because they are not recorded in any source VM’s checkpoints, but they are already recorded in some checkpoint of a destination VM. In the [wiki:VDEchp VDEchp] design, there is always a correct state for the VM, recorded as the stable copy in the disk. The state of stable copy is one checkpoint interval behind the current VM’s state, because we copy the last checkpoint to the stable copy only when we get a new checkpoint. Therefore, before a checkpoint is committed by copying to the stable copy, we buffer all the outgoing messages in the VM during the corresponding checkpoint interval. Thus, type (3) messages are never generated, because the buffered messages are unblocked only after saving their information by copying the checkpoint to the in-disk stable copy. Our algorithm works under the assumption that the buffered messages will not be lost or duplicated.
 
-In the [wiki:VDEchp VDEchp] design, there are multiple VMs running on different hosts connected within the network. One host is the backup host where we deploy the [wiki:VDEchp VDEchp] Initiator, and others are primary hosts where we run the protected VMs. The Initiator can be running on a VM which is dedicated to the checkpointing service. It doesn’t need to be deployed on the privileged guest system like the Domain 0 in Xen. When [wiki:VDEchp VDEchp] starts to record the globally consistent checkpoint, the Initiator broadcasts the checkpoint request and waits for acknowledgements from all the recipients. Upon receiving a checkpoint request, each VM checks the latest recorded in-disk stable copy (not the in-memory checkpoint), marks this stable copy as part of the global checkpoint, and sends a “success” acknowledgement back to the Initiator. The algorithm terminates when the Initiator receives the acknowledgements from all the VMs. For example, if the Initiator sends a request (marked as rn) to checkpoint the entire VDE, a VM named VM1 in the VDE will record a stable copy named “vm1 global rn”. All of the stable copies from each VM compose a globally consistent checkpoint for the entire VDE. Besides, if the [wiki:VDEchp VDEchp] Initiator sends the checkpoint request at a user-specified frequency, the correct state of the entire VDE is recorded periodically.
+In the [wiki:VDEchp VDEchp] design, there are multiple VMs running on different hosts connected within the network. One host is the backup host where we deploy the [wiki:VDEchp VDEchp] Initiator, and others are primary hosts where we run the protected VMs. The Initiator can be running on a VM which is dedicated to the checkpointing service. It doesn’t need to be deployed on the privileged guest system like the Domain 0 in Xen. When [wiki:VDEchp VDEchp] starts to record the globally consistent checkpoint, the Initiator broadcasts the checkpoint request and waits for acknowledgements from all the recipients. Upon receiving a checkpoint request, each VM checks the latest recorded in-disk stable copy (not the in-memory checkpoint), marks this stable copy as part of the global checkpoint, and sends a “success” acknowledgement back to the Initiator. The algorithm terminates when the Initiator receives the acknowledgements from all the VMs. For example, if the Initiator sends a request (marked as rn) to checkpoint the entire VDE, a VM named VM,,1,, in the VDE will record a stable copy named “vm1_global_rn”. All of the stable copies from each VM compose a globally consistent checkpoint for the entire VDE. Besides, if the [wiki:VDEchp VDEchp] Initiator sends the checkpoint request at a user-specified frequency, the correct state of the entire VDE is recorded periodically.
 
 == Evaluation Results ==